MySQL:增加数据库中的文本ID

发布于 2024-10-06 19:51:48 字数 343 浏览 4 评论 0原文

我的应用程序中需要有文本 ID。 例如,我们有可接受的字符集 azAZ09,以及允许的 ID 范围 [aaa] - [cZ9]。第一个生成的 id 是 aaa,然后是 aab、aac、aad 等

如何返回 ID 和 ID?增加交易方式的下限? (假设有数百个并发请求,并且所有请求都应该有正确的结果)

为了降低负载,我想可以定义 20 个单独的范围,并从随机范围返回 id - 这应该减少争用,但不清楚如何做首先是单一操作。

另请注意,范围内的 ID 数量可能会超过 2^32。

另一个想法是拥有 64 位整数范围,并在软件代码中转换整数->字符 id,这可以异步完成。

有什么想法吗?

I need to have text IDs in my application.
For example, we have acceptable charset azAZ09, and allowed range of IDs [aaa] - [cZ9]. First generated id would be aaa, then aab, aac, aad e.t.c.

How one can return ID & increment lower bound in transaction-fashion? (provided that there are hundreds of concurrent requests and all should have correct result)

To lower the load I guess it's possible to define say 20 separate ranges, and return id from random range - this should reduce contention, but it's not clear how to do single operation in the first place.

Also, please note that number of IDs in range might exceed 2^32.

Another idea is having ranges of 64-bit integers, and converting integer->char id in software code, where it could be done asyncroniously.

Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

感情洁癖 2024-10-13 19:51:48

一种基于long (bigint)数字的解决方案,在软件中完成字符到数字和数字到字符的转换,有 - 比如说 - 32个不同的范围,

  • 创建32个表范围0 .. range31 以降低负载(具有 32 个范围字段的唯一表将在每次写入范围时锁定其行)

  • 通过将 auto_increment 设置为 64 位上的非常高的值来启动范围 - 如果您想避免符号,则可以为 63您的应用程序中存在问题。理想情况下,范围值为 5 位,从 0 到 31。1 位符号 + 5 位范围 = 6 位。您的计数器将从 1 到 (2^58-1) 或 10^17...这应该足够了。

  • 在软件中,范围编号是随机选择的,查询表名称是相应构建的范围i,其中i从0到31 .

创建表命令类似于 Java 中的命令

  String table;
  String query;
  long increment;

  for (long i=0 ; i<32 ; i++) {
    table = "range"+i;
    increment = (i<<58) + 1;
    query = "CREATE TABLE "+table+" (v bigint auto_increment primary key) auto_increment="+increment;

    do_query(query);
  }

A solution based on long (bigint) numbers, with chars-to-number and number-to-chars conversions done in software, having - say - 32 differents ranges,

  • creation of 32 tables range0 .. range31 to lower the load (a unique table with 32 range fields would have its row locked each time a range is written to)

  • starting the ranges by setting the auto_increment to a very high value on 64 bits - maybe 63 if you want to avoid the sign problem in your application. Ideally the range value on 5 bits, from 0 to 31. 1 bit sign + 5 bits range = 6 bits. You counter will be from 1 to (2^58-1) or 10^17... that should be enough.

  • in software the range number is selected randomly, and the query table name is built accordingly rangei where i goes from 0 to 31.

The create tables commands would be something like, say in Java

  String table;
  String query;
  long increment;

  for (long i=0 ; i<32 ; i++) {
    table = "range"+i;
    increment = (i<<58) + 1;
    query = "CREATE TABLE "+table+" (v bigint auto_increment primary key) auto_increment="+increment;

    do_query(query);
  }
诠释孤独 2024-10-13 19:51:48

我会问一个不同的问题,以使同一问题更容易解决:如何使用数据库的功能来实现我的要求。

查看您的数据库在管理序列方面提供的功能。他们中的一些人可能会处理类似的事情。如果你的数据库没有,我会看看它的正常数字键上的“小猪支持”,因为它们已经解决了你预期的所有问题。

我的意思是这样的:让数据库像平常一样分发数字键,从 0 开始。然后编写两个函数在这些数字和文本键之间进行转换。这里有一定的灵活性:您可以在数据库中(使用第二列、触发器或一些很酷的数据库功能)或在服务器层(例如 Java)中实现此功能。事情不会那么复杂。最后,无论如何,这都是位......您的文本键只是对位进行切片的不同方式。

祝你好运!

I'd ask a different question to make the same problem easier to solve: how can I use the features of my database to implement my requirement.

Look at what your database offers in terms of managing the sequences. Some of them may handle something like this. If you database doesn't, I'd look at "piggy backing" on it's normal numeric keys, since they already solve all the problems you are anticipating.

What I means is this: Let the database hand out numeric keys as it normally does, starting at 0. Then write two functions to convert between those numbers and your text keys. You have some flexibility here: you can implement this function in the database (using a second column, triggers, or some cool database feature), or at your server layer, like Java. It won't be that complicated. In the end, it's all bits anyhow... you text key is just a different way to slice up the bits.

Good luck!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文