Отслеживание включения / выключения без таблиц только для индекса

Question

Я ищу лучший, самый масштабируемый способ отслеживания большого количества включений / выключений.Включения / выключения относятся к предметам, насчитывающим от 1 до около 60 миллионов.(В моем случае включение / выключение означает, была ли книга участника проиндексирована или нет, это отдельный процесс.)

Включение / выключение необходимо быстро искать по номеру элемента.Они постоянно меняются, поэтому затраты на переиндексацию не могут быть высокими.Новые элементы добавляются в конец таблицы реже.

Идеальным решением, как мне кажется, будет таблица только для индекса - таблица, в которой каждое поле является частью первичного ключа.Я полагаю, что у ORACLE это есть, но нет движка для MySQL.

Если я использую MySQL, я думаю, что мой выбор между:

1. таблица с двумя полями--пункт и поле «вкл / выкл».Изменения будут обрабатываться с помощью UPDATE.

2. таблица из одного поля - элемент.Быть за столом - значит быть «включен».Изменения обрабатываются с помощью INSERT и DELETE.

Я открыт для других технологий.Битовое хранение всего этого в файле?

Answer 1

Используя опцию № 1, вы можете добиться большей гибкости, но обе будут работать эффективно. Однако, если скорость является проблемой, вы можете рассмотреть возможность создания таблицы HEAP, которая предварительно заполняется при запуске mysql и поддерживается на месте с другими вашими процессами. Также используйте в таблице типы полей int и enum. Поскольку все это будет храниться в памяти, оно должно быть молниеносным, а поскольку в таблице хранится не так много данных, 60 миллионов записей не должны быть огромным бременем с точки зрения памяти. Если бы мне пришлось примерно оценить:

int (8) (для роста, если вы когда-нибудь превысите 100 миллионов записей)

перечисление (0,1)

Итак, давайте округлим до 10 байтов на запись:

10 * 60 000 000 = 600 000 000

Это примерно 572 МБ данных, плюс индекс и дополнительные накладные расходы, так что скажем грубо ... таблица 600 МБ. Если у вас есть такой тип памяти, который вы можете сэкономить на своем сервере, тогда вам может пригодиться таблица HEAP.

Answer 2

60 миллионов строк с идентификатором и битом включения / выключения не должно быть проблемой для MySQL, если вы используете InnoDB.

У меня есть таблица InnoDB, которая отслеживает, какие темы форума прочитали пользователи и какую статью они прочитали. Он содержит 250 миллионов строк, имеет ширину 14 байт и постоянно обновляется ... Сейчас он выполняет 50 обновлений в секунду, и сейчас полночь, поэтому пиковое время может быть 100-200 ?.

Индексированные столбцы не обновляются после вставки. Первичный ключ (user_id, topic_id), и я добавляю новую информацию last_read, используя INSERT ... ON DUPLICATE KEY UPDATE.

Я измеряю постоянно и не вижу проблем с конкуренцией или производительностью, но я делаю кэш-чтения много в memcached, так как решить, когда истечь срок действия кэша, очень просто. Я рассматривал возможность разделения этой таблицы пользователем, чтобы контролировать рост, но, возможно, даже не буду вечно хранить ее в MySQL.

Я открыт для других технологий. Битовое хранилище целиком в файле?

Redis была бы отличной альтернативой. В частности, его наборы и отсортированные наборы будут работать для этого (отсортированные наборы могут быть полезны, если вам нужно получить диапазон значений, используя что-то отличное от идентификатора элемента - как последнее обновление время)

Redis, возможно, стоит проверить, если вы еще этого не сделали - это может быть отличным дополнением к приложению, использующему MySQL, и вы, вероятно, найдете для него другие полезные варианты, которые упростят вашу жизнь.