Какую БД следует использовать?

Question

Теперь я создаю приложение, которое должно хранить и обрабатывать большие объемы данных. Так что теперь я борюсь с вопросом - какую БД я должен использовать.

Мои требования:

• Обрабатывать до ~ 100000 вставки команд в секунду (иногда несколько из них из разных потоков). 100 000 - это пик; В большинстве случаев сумма будет составлять от нескольких сотен до нескольких тысяч.
• Хранить миллионы записей.
• Запрос данных как можно быстрее.
• Часть свойств данных изменяется для каждого объекта, который подходит для поведения, не относящегося к реляционной базе данных, более реляционных. Однако сумма возможных свойств невелика, поэтому ее можно представить в виде столбцов в реляционной базе данных (если она намного быстрее).
• Команды обновления редко встречаются.

Какой-нибудь БД вы бы посоветовал мне использовать?

Спасибо!

Обновление: OS, которую я использую, не является Windows. Я думал, что если SQL Server будет самой рекомендуемой БД, тогда я могу переключиться, но из ваших ответов это не так.

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

Никто не рекомендовал базы данных no-sql. Неужели это так плохо для такого рода требований?

Answer 1

Ответ на вопрос о дополнительных вопросах, например, сколько вы хотите потратить, какую ОС вы используете и какой опыт у вас есть в доме.

База данных, которую я знаю, может обрабатывать такой массивный масштаб: DB2, Oracle, Teradata и SQL Server. MySQL также может быть вариантом, хотя я не уверен в его возможностях производительности.

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

Итак, если ваша ОС не является Windows, вы можете исключить SQL Server.

Если вы собираетесь недорого, MySQL может быть вариантом.

DB2 и Oracle являются зрелыми системами баз данных. Если ваша система является мэйнфреймом (IBM 370), я бы рекомендовал DB2, но для Unix-based может быть вариант.

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

Более полный список вариантов можно найти здесь: http://en.wikipedia.org/wiki/List_of_relational_database_management_systems

Порядочный comparason базы данных здесь: http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

100000+ вставляет второй огромное количество, независимо от того, что вы выбираете, вы не глядя на то, чтобы потратить целое состояние на оборудование, чтобы справиться с этим.

Answer 2

«Обработать до 100 000 команд вставки в секунду» - этот пик или нормальная работа? Если нормальная работа, ваши «миллионы зарегистрированных записей», вероятно, будут миллиардами ...

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

Если необходимо, то вы можете рассмотреть возможность использования агрегирования/преобразования данных (массовая загрузка данных/отбрасывание нескольких обновлений в одну и ту же запись/загрузку в многоуровневые базы данных, а затем объединение вниз по течению в виде объединенного набора ETL возможно), чтобы упростить управление этим томом.

Answer 3

Первое, о чем бы я беспокоился, это ваш дисковый макет, у вас смешанная рабочая нагрузка (OLTP и OLAP), поэтому чрезвычайно важно, чтобы ваши диски были отсортированы и правильно установлены для достижения этой пропускной способности, если ваш IO подсистема не может обрабатывать нагрузку, тогда не имеет значения, какая БД вы будете использовать

Кроме того, возможно, что 100 000 вставок в секунду могут быть загружены навалом, битва 100 000 строк в секунду составляет 72 000 000 строк всего за 12 часов, поэтому, возможно, вы хотите сохранить миллиарды строк?

Answer 4

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

В любом случае ни одна нить не сможет выполнять многие команды, поэтому я ожидаю, что там будут 100-1000 потоков, которые будут делать эти вставки.

В зависимости от вашего приложения вам, вероятно, потребуется какая-то высокая доступность. Если вы не делаете что-то вроде научного приложения.

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

Answer 5

Это не вопрос о том, какую БД выбрать, это вопрос о ваших навыках и опыте.

Если вы считаете, что это возможно с помощью одной физической машины - вы ошибаетесь. Если вы знаете, что нужно использовать несколько машин - тогда почему вы спрашиваете о БД? DB не так важен, как вы с ним работаете.

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