Comments 13
Интересный способ обеспечения уникальности ключа (если бы еще эта часть была расписана полнее :) ).
Но как быть, если у нас в секунду более 1024 INSERT-ов в одну таблицу?
Но как быть, если у нас в секунду более 1024 INSERT-ов в одну таблицу?
Поправка: 1024 тысяч INSERT-ов в секунду.
>1024 тысяч INSERT-ов в секунду.
супер круто,
а БД способна выдержать такую нагрузку???
супер круто,
а БД способна выдержать такую нагрузку???
БД способна выдержать любую нагрузку.
Другой вопрос, готово ли к этому железо…
Для PostgreSQL встречал оценку в 50 000 INSERT-ов в секунду (но это были только рассуждения о возможностях «выжать максимум» (RAM-drive и т.д.)).
Тесты на реальном железе говорят о 1200 INSERT-ов (но это были довольно старые оценки, сейчас максимум раз в 10-20 выросла данная оценка).
Так что ни о каком миллионе INSERT-ов в секунду пока речь не идет. Но есть куда стремиться )
P.S. на счет тяжести INSERTa — если верить этому, UPDATE = DELETE + INSERT, так что UPDATE легче INSERTа быть не может (в общем случае).
Другой вопрос, готово ли к этому железо…
Для PostgreSQL встречал оценку в 50 000 INSERT-ов в секунду (но это были только рассуждения о возможностях «выжать максимум» (RAM-drive и т.д.)).
Тесты на реальном железе говорят о 1200 INSERT-ов (но это были довольно старые оценки, сейчас максимум раз в 10-20 выросла данная оценка).
Так что ни о каком миллионе INSERT-ов в секунду пока речь не идет. Но есть куда стремиться )
P.S. на счет тяжести INSERTa — если верить этому, UPDATE = DELETE + INSERT, так что UPDATE легче INSERTа быть не может (в общем случае).
не забываем, что INSERT самая «тяжелая» операция,
Чудес не получится, можно взять несколько бит только с shard_id, тем самым ослабив его (что не есть гуд).
Я ошибся, не 1024, а 1024 тысячи INSERT-ов в секунду (т.е. 1024 в миллисекунду), что, на сколько могу судить, на несколько порядков больше современных возможностей техники.
Но лет через 10 проблема станет актуальнее.
У Instagram это приводится как факт, что мы генерируем только 1024 значения в миллисекунду, просто интересно, а есть ли алгоритмы, теоретически позволяющие обходить данную проблему.
Хотя я один такой знаю. Берем простое число и на каждой итерации прибавляем к предыдущему значению его. Тогда имея для каждого сервера свое такое уникальное число, можно быть уверенным, что они не пересекутся. Проще было бы брать каждое N-е число (N-число серверов), но тогда добавлять сервера проблемно.
Но лет через 10 проблема станет актуальнее.
У Instagram это приводится как факт, что мы генерируем только 1024 значения в миллисекунду, просто интересно, а есть ли алгоритмы, теоретически позволяющие обходить данную проблему.
Хотя я один такой знаю. Берем простое число и на каждой итерации прибавляем к предыдущему значению его. Тогда имея для каждого сервера свое такое уникальное число, можно быть уверенным, что они не пересекутся. Проще было бы брать каждое N-е число (N-число серверов), но тогда добавлять сервера проблемно.
Эта часть описана подробно Instagram
Переведите все на UUID.
CREATE TABLE… (
pk_XXX UUID PRIMARY KEY,
…
);
А для генерации UUID например такой код
import uuid
…
...uuid.uuid1()…
…
Из документации по python
uuid.uuid1([node[, clock_seq]])
Generate a UUID from a host ID, sequence number, and the current time. If node is not given, getnode() is used to obtain the hardware address. If clock_seq is given, it is used as the sequence number; otherwise a random 14-bit sequence number is chosen.
CREATE TABLE… (
pk_XXX UUID PRIMARY KEY,
…
);
А для генерации UUID например такой код
import uuid
…
...uuid.uuid1()…
…
Из документации по python
uuid.uuid1([node[, clock_seq]])
Generate a UUID from a host ID, sequence number, and the current time. If node is not given, getnode() is used to obtain the hardware address. If clock_seq is given, it is used as the sequence number; otherwise a random 14-bit sequence number is chosen.
Sign up to leave a comment.
PostgreSQL: Уникальные ключи для распределенной базы. Практика