Дизайн базы данных - миллиарды записей в одной таблице?

Question

Допустим, вы создаете базу данных для хранения сообщений для приложения чата. Существует бесконечное количество комнат чата (они создаются во время выполнения по требованию), и все сообщения должны храниться в базе данных.

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

Было бы разумнее динамически создавать таблицу для каждой созданной комнаты и хранить сообщения этой комнаты только в этой таблице?

Answer 1

миллиардов записей?

Если у вас постоянно 1000 активных пользователей с 1 сообщением в минуту, это приводит к 1,5 млн. Сообщений в день и примерно 500 млн. Сообщений в год.

Если вам все еще нужно хранить сообщения чата нескольких лет (зачем?), Вы можете заархивировать их в таблицы по годам.

Я бы определенно высказался против динамического создания столов на основе комнаты.

Answer 2

Было бы правильно иметь одну таблицу. Когда у вас есть n таблиц, которые растут в зависимости от использования приложения, вы описываете использование самой базы данных в виде таблицы таблиц, а это не то, как RDBMS предназначена для работы. Миллиарды записей в одной таблице тривиальны в современной базе данных. На этом уровне ваши единственные проблемы с производительностью - это хорошие показатели и то, как вы объединяетесь.

Answer 3

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

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

Вы можете разделить сообщения по диапазону дат, и, если запланировано, вы можете использовать миграцию LUN для перемещения старых данных в более медленное хранилище, оставляя более свежие данные в более быстром хранилище.

Answer 4

Строго говоря, ваш дизайн правильный, единый стол. поля с низкой энтропией {например, «идентификатор пользователя» - вы хотите связать из таблиц идентификаторов, т.е. следуя обычным шаблонам нормализации базы данных}

Вы можете подумать о разделении на основе диапазона. например, «копии» вашей таблицы с префиксом года. Или, может быть, просто «текущая» и архивная таблица

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

однако, положительным моментом является то, что ваша «текущая» таблица останется примерно постоянной величины, а архивирование будет более простым. - {вы можете просто удалить таблицу 2005_Чат, когда хотите архивировать данные 2005 года}

1009 *-ACE *