Хранение массивов целых чисел в базе данных

Question

Я создаю базу данных, которая будет хранить 100 000 (и, вероятно, больше в будущем) пользователей.Хотя это очевидно происходит в таблице с 1 строкой на пользователя, каждый пользователь может (и будет) хранить сотни элементов.В языке программирования это означает, что у пользователя есть 2 массива (или один 2-мерный массив) целых чисел: столбец для itemid и столбец для сумм.

Мои инстинкты говорят мне создать таблицу для хранениявсе эти элементы, с такими строками, как (ID пользователя, ItemID, количество).Однако это привело бы к огромной таблице.200 000 пользователей по 250 наименований в каждом ... это 50 миллионов записей в одной таблице.Это, плюс тот факт, что стол будет подвергаться постоянным и быстрым изменениям, пугает меня.(Как быстро? Я оцениваю до 100 модификаций в секунду.)

Как правило, будет от 100 до 2000 пользователей, добавляющих и удаляющих элементы, а также изменяющих суммы.Эти действия могут и будут происходить в программном коде.Это будет выглядеть следующим образом:

• Пользователь начинает сеанс, программа загружает все элементы пользователя из базы данных
• Пользователь изменяет список элементов
• Каждые несколько минутизменения сохраняются в базе данных
• Когда пользователь завершает сеанс, он также сохраняется в базе данных

Стоит отметить, что существует максимальное количество элементов впользователь может хранить.

Есть ли альтернативы использованию отдельной таблицы?Возможно сохранить значения в форматированной текстовой строке?Или это один из случаев, когда использование базы данных MySQL на самом деле является плохой идеей ™?

Спасибо за ваше время и идеи.

Answer 1

Мои инстинкты говорят мне создать таблицу для хранения всех этих предметов

Ваши инстинкты правы.

1) избегать преждевременной оптимизации

2) не нарушайте правила нормализации, если у вас нет для этого веской и реальной причины

3) почему вы подозреваете, что многостоловый подход будет быстрее?

это 50 миллионов записей в одной таблице

И что? Даже если у вас есть только индекс для идентификатора пользователя, разница в производительности по сравнению с одной таблицей на пользователя не будет заметно медленнее (на практике с 200 000 пользователей это будет намного, намного быстрее - поскольку СУБД может с удобством держать открытыми дескриптор файла для каждой таблицы!).

Я оцениваю до 100 модификаций в секунду

Должно быть возможно использовать MySQL и довольно простое аппаратное обеспечение, но если бы это был я, и я хотел бы немного сэкономить, я бы выбрал пару зеркальных дисков SATA, таблицы на одном зеркале, индексы на другом.

Единственная проблема, о которой я буду беспокоиться (которая применяется независимо от того, какую из двух моделей вы выберете), - это поддержка 2000 одновременных подключений. Должны ли соединения быть параллельными? Или каждый пользователь может загрузить рабочий набор (возможно, используя оптимистическую стратегию блокировки) и закрыть соединение, а затем отменить изменения в новом соединении? Если нет, то вам, вероятно, понадобится хороший запас памяти и процессора.

Но если оставить в стороне, использовать ли одну большую таблицу или множество маленьких, если это единственное использование для данных, а доступ не параллелен к конкретным элементам данных, тогда зачем вообще беспокоиться о реляционной базе данных? NoSQL или общая файловая система могут работать так же хорошо.

Answer 2

Помещение данных в одно поле в виде массива всегда всегда является ошибкой. Это делает запрос данных намного сложнее и требует гораздо больше времени, а также значительно снижает вероятность использования индексов. Это нормально, если бы значения были просто текстовыми, где вам никогда не понадобилось бы находить один или несколько элементов для массива, но, по моему опыту, такая ситуация встречается редко. Современные базы данных могут обрабатывать 50 миллионов записей, даже не потея. Это небольшая таблица в терминах базы данных.

Answer 3

Все должно быть в порядке, как вы описали, используя две таблицы. База данных должна иметь возможность обрабатывать миллионы записей.

Важные моменты, на которые следует обратить внимание:

1- Оптимизируйте ваши запросы в максимально возможной степени.

2- Создайте соответствующие индексы для ускорения ваших запросов.

3 - Используйте InnoDB, если у вас есть параллельные операции чтения / обновления, поскольку он поддерживает блокировку на уровне строк, в отличие от MyISAM.

4 - Обеспечить хорошее оборудование для поддержки сервера базы данных.

5 - Запустите сервер базы данных на выделенном сервере, если это возможно.