Проектирование базы данных SQL для огромных наборов данных

Question

У меня есть клиент, имеющий следующую структуру данных ... для каждого пациента может быть несколько выборок, и каждая выборка после обработки может иметь 4 миллиона объектов данных.Максимальное количество выборок на пациента составляет 20. Таким образом, у одного пациента может оказаться 80 миллионов строк данных, и, конечно, в конечном итоге будет много и много сотен пациентов.

При настройке базы данных для храненияС объектами (каждый из которых содержит около 30 полей статистики и измерений) задача довольно ясна: как управлять этим огромным количеством данных?

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

У моего коллеги было интересное предложение, заключающееся в том, чтобы сделать еще один шаг вперед - создать новую базу данных для каждого пациента и затем иметь таблицу для выборки.Он думал, что иметь 1 журнал на пациента, иметь возможность перемещать базы данных на каждого пациента и т. Д. Было хорошо.Я не могу с ним не согласиться.

Это разумно?Это плохая идея по какой-то причине иметь много баз данных?

Мысли?Спасибо!

Answer 1

Несмотря на то, что идея интересна с точки зрения конфиденциальности и миграции, не стоит иметь единую базу данных на пациента.Подумайте об управлении, резервном копировании, наличии файлов для каждой базы данных пациентов.Я даже не уверен, что СУБД может одновременно обрабатывать миллионы баз данных в экземпляре или на сервере.

Что я хотел бы сделать, принять объемные данные как фактические данные и разобраться с ними вТип параметров и таблиц вы выбираете.Пусть СУБД беспокоится об этом.Убедитесь, что у вас есть модель развертывания, позволяющая увеличивать и уменьшать масштаб ваших таблиц.Таблица для каждой сущности, по крайней мере, была бы разумной, поэтому для пациента, измерения и т. Д.

Просто делайте то, что вам нужно в качестве разработчика, и позвольте СУБД делать то, для чего она создана.

Answer 2

При работе с таким большим количеством данных вам определенно понадобится изучить альтернативы MySQL и RDBMS.Вы смотрели на какие-либо решения NoSQL?(т.е. хранилища значений ключей).Существует несколько решений с открытым исходным кодом, некоторые из которых сразу не подойдут для данного приложения, учитывая, что любая потеря данных, вероятно, недопустима.

Возможно, попробуйте взглянуть на Cassandra Apache http://cassandra.apache.org/. Это распределенная система баз данных (хранилище ключей-значений), но она может работать и на одном узле.Это позволит вам хранить все ваши данные для каждого пациента под одним ключевым значением «т.е. Patient1», а затем вы сможете организовать свои данные в любую структуру ключ-значение, которая лучше всего подходит для запросов в вашем приложении.