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

Question

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

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

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

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

Спасибо!

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Приличный сравнитель базы данных здесь: http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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