|
|
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
Всем добрый день! Разрабатываем большой портал. СУБД: Postgre. Так как предполагаем, что в будущем, возможно, нужно будет кластеризировать данные, хотим предусмотреть это в первичных ключах таблиц базы данных. Кроме того, планируем fail-over переключения на резервный сервер базы данных. И это тоже нужно предусматривать в первичных ключах К примеру, если мы сделаем первичные ключи autoincrement, то на разных серверах могут возникнуть данные с одним и теми же ключами, что недопустимо. Потом мы подумали использовать в качестве первичного ключа GUID. Но это 128 бит, и скорость джойнов и поиска по идентификатору будет не такой эффективной, как по int64 в 64битных серверах. Поэтому сейчас остановились на идее генерировать в базе данных уникальные в пределах портала уникальные идентификаторы формата int64. Чтобы на разных серверах БД они не повторялись. В связи с этим два вопроса: 1) Действительно ли мы правильно заморачиваемся? Или есть другой, более эффективный способ позволить Postgre работать в кластере и поддерживать работу базы данных в режиме fail-over? 2) Если мы все же правильно заморачиваемся, подскажите, пожалуйста, java-библиотеку, или хотя бы эффективный алгоритм генерации уникальных в рамках всех своих серверов int64 ключей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2012, 19:13:10 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2012, 19:29:04 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
GUID не уникален, поэтому использовать его для первичных ключей не есть гуд, т.к. рискуете нарваться на проблему на ровном месте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2012, 19:53:08 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
grasoff.net http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html#getMostSignificantBits() А разве это будет уникальное значение в рамках всего моего набора серверов? TrogloditGUID не уникален, поэтому использовать его для первичных ключей не есть гуд, т.к. рискуете нарваться на проблему на ровном месте. Что??? С каких это пор GUID не уникален??? И какую альтернативу Вы предлагаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2012, 19:56:48 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
Vetal, мне кажется кластеризация не зависит от первичных ключей. Иначе где пресловутая горизонтальная масштабируемость? 1C добавляет префикс к ключам в филиалах. Но это не тот подход, который нужно копировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2012, 20:02:46 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
grasoff.net http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html#getMostSignificantBits() Посмотрел я, что хранится в старших байтах: 0xFFFFFFFF00000000 time_low 0x00000000FFFF0000 time_mid 0x000000000000F000 version 0x0000000000000FFF time_hi При этом version - это тип ключа, он для всех одинаков. А остальное - это текущее время. Чисто теоретически может возникнуть ситуация, что два параллельных сервера сгенерят ключ в одно и то же время. Или в реальной жизни такого не будет? Может, лучше свой алгоритм, где есть три части? Идентификатор сервера, timestamp и некий sequence number? Возможно, есть готовая библиотека для этого на java? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2012, 20:04:01 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
когда-то IBM месяц делал тест - вставки на 100 нодах ничего не повторилось ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 07:07:14 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
VetalНо это 128 бит, и скорость джойнов и поиска по идентификатору будет не такой эффективной, как по int64 в 64битных серверах. А что показывают результаты измерений на реальных базах и запросах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 07:16:12 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
KyubeeVetalНо это 128 бит, и скорость джойнов и поиска по идентификатору будет не такой эффективной, как по int64 в 64битных серверах. А что показывают результаты измерений на реальных базах и запросах?мне вот тоже интересно если Код: sql 1. 2. 3. 4. то что показывают результаты по "скорость джойнов и поиска по идентификатору будет не такой эффективной, как по int64 в 64битных серверах"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 10:13:44 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
Vetal2) Если мы все же правильно заморачиваемся, подскажите, пожалуйста, java-библиотеку, или хотя бы эффективный алгоритм генерации уникальных в рамках всех своих серверов int64 ключей? Twitter Snowflake . У них хотя и MySQL, но проблема явно похожая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 10:16:16 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
Lepsikкогда-то IBM месяц делал тест - вставки на 100 нодах ничего не повторилось Что именно делал IBM? Тестирование на вставку именно 64битного ключа, который является первой частью стандартного UUID? Или что за тест? KyubeeVetalНо это 128 бит, и скорость джойнов и поиска по идентификатору будет не такой эффективной, как по int64 в 64битных серверах. А что показывают результаты измерений на реальных базах и запросах? Я не знаю, мы, для начала, храним этот идентификатор как char(32). Это даже 256 бит. Как лучше хранить UUID в Postgre - непонятно. Абсолютно логично, что работа с такими ключами будет на 64битных системах дольше, чем с int64. Замерять не замеряли. Не видим смысла в этом, и так понятно, что быстрей будет. Или Вы считаете, что все же разница между джойнами и поисками по char(32) и int64 будет непринципиальна? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 14:04:58 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
Добрый день, Vetal! > Разрабатываем большой портал. СУБД: Postgre. Так как предполагаем, что в > будущем, возможно, нужно будет кластеризировать данные, хотим > предусмотреть это в первичных ключах таблиц базы данных. Кроме того, > планируем fail-over переключения на резервный сервер базы данных. И это > тоже нужно предусматривать в первичных ключах > > К примеру, если мы сделаем первичные ключи autoincrement, то на разных > серверах могут возникнуть данные с одним и теми же ключами, что недопустимо. А если из 64 бит заложить 8 на ID сервера, а остальное- на собственно ID? Хотя да, есть некоторая некрасивость решения. > Потом мы подумали использовать в качестве первичного ключа GUID. Но это > 128 бит, и скорость джойнов и поиска по идентификатору будет не такой > эффективной, как по int64 в 64битных серверах. Я думаю, что разницу вряд ли можно уловить. Прямая ссылка вообще имеет нулевую стоимость в сравнении с накладными расходами сети, выборки данных и т.п. -- Алексей JID: alxt@ya.ru Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 14:20:47 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
Вобщем, взял идею из Snowflake, и заимплементил свой генератор. Выкладываю сюда, мне не жалко: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 20:31:18 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
Кроме того, планируем fail-over переключения на резервный сервер базы данных. И это тоже нужно предусматривать в первичных ключах К примеру, если мы сделаем первичные ключи autoincrement, то на разных серверах могут возникнуть данные с одним и теми же ключами, что недопустимо. Постгрес же умеет только реплицировать один в один. Поэтому в одной базе не смогут появиться записи из разных баз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 21:17:53 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
Vetalхраним этот идентификатор как char(32). Это даже 256 бит. Как лучше хранить UUID в Postgre - непонятно Не постгресовод, но гоголь подсказывает что guid появился с 8.3 Vetalразница между джойнами и поисками по char(32) и int64 будет непринципиальна? На микрософте было сравнение int32 и guid, и таки да, непринципиально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 21:23:13 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
Vetal, мне непонятно: - вы данный вопрос на форуме СУБД спрашивали? Или хотите обойтись без неё (как всегда) средствами кластеризации Java. - какие конкретно требования по "сабжу в гарммах"? авторРечь идёт о миллисекундах. Текущая выборка занимает 150-300 мс нужно сократить до 15 - 30 мс. Кластер из 10 Atom D2700 vs один i7-2600 ЗЫ. Если бы кластеры делались через ключи БД (Модель), тут у каждого второго бы они были. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 21:41:21 |
|
||
|
Как сгенерировать int64 ключи для кластеризированной базы данных?
|
|||
|---|---|---|---|
|
#18+
1) Vetal, капец. Проблемы на ровном месте. Создаете на двух узлае сиквенсы с разными стартовыми условиями и имеете уникальность на ближайшие лет 10-20. Node1: Код: plsql 1. 2. 3. 4. Node2: Код: plsql 1. 2. 3. 4. А после 20 лет ... ну или ишак сдохнет или Султан. 2) По поводу SYSGUID. Алгоритм его генерации - неоднозначен. Разные имплементации могут учитывать или не учитывать MAC-адрес сетевого интерфейса (кст. какого?) учитывать или не учитывать дату и т.п. Так что относитесь к SYSGUID просто как формату 128-битного целого. А алгоритм генерации - ваш собственный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2012, 23:20:18 |
|
||
|
|

start [/forum/topic.php?fid=59&tid=2132024]: |
0ms |
get settings: |
12ms |
get forum list: |
22ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
58ms |
get topic data: |
20ms |
get forum data: |
5ms |
get page messages: |
83ms |
get tp. blocked users: |
3ms |
| others: | 346ms |
| total: | 561ms |

| 0 / 0 |
