Я ищу некоторые веские основания для выбора между Oracle и SQL Server для обработки около 5-6 терабайт данных. Эти данные будут накапливаться в течение 8 месяцев. Все данные старше 8 месяцев удаляются из базы данных.
Я рассматриваю Oracle 11G Standard Edition и SQL Server 2008 Standard Edition.
Я не ищу простоты разработки, я просто ищу возможность обрабатывать огромные данные и при этом обеспечивать хорошую производительность. Помимо производительности, если есть какой-либо параметр, который имеет значение, выделите его.
Я знаю, что по цене есть большая разница, но это не фактор, если разница в производительности большая.
Надеюсь на объективные ответы и без религиозной войны.
Вам не понравится этот ответ, но и то же самое. Oracle и MS SQL Server примерно равны с точки зрения крупномасштабной обработки данных (SQL Server может иметь преимущество в простоте использования, Oracle - в утилите), и когда дело доходит до необработанных данных, PostgreSQL может фактически обойти их обоих. с очень небольшим запасом при оптимизации.
Но если вам действительно нужна «большая» база данных, которая доказала свою эффективность при законном использовании столбцов с 64-битными идентификаторами и ТБ данных, то это (IBM) DB2.
(Что касается религиозных войн, я специалист по SQL Server, но даже я знаю его пределы)
Я полагаю, это действительно будет зависеть от того, что могут поддерживать разработчики приложений и операторы; Я полагаю, что вы не будете хранить этот набор данных на одном сервере для обеспечения избыточности и производительности.
Если вы пишете 6 ТБ в течение 8 месяцев, это на самом деле не является большой скоростью вставки, поэтому отток данных не будет проблемой для любого достойного оборудования.
Большая часть производительности будет зависеть от правильной конструкции, которая в некоторой степени будет зависеть от характеристик конкретного используемого продукта.
Без правильного проектирования для обоих, а затем сравнения полностью прототипированного приложения с производственными объемами данных вы не сможете их сравнивать. Я предполагаю, что это будет неэффективно с точки зрения затрат (усилия разработчика по созданию ДВУХ прототипов и их тестированию при полной загрузке данных на оборудовании промышленного уровня).
Я полагаю, что любой из них отлично справился бы с этой задачей, как и все, что вы хотите назвать. Все дело в правильном дизайне приложения, правильном использовании специфических особенностей базы данных.
Это полностью зависит от того, что это за данные, как они хранятся и что вы делаете с данными.
Если предположить, что это одна таблица, то у Oracle, безусловно, есть для этого «отбивные», но вам понадобится корпоративная версия с возможностью разделения. При этом вы можете разделить свои данные на месяцы, недели, дни или часы, что угодно. Тогда легко будет сохранить ваше скользящее 8-месячное окно (я предполагаю, что это скользящее окно, а не только то, что через 8 месяцев все это будет привязано).
С любым решением вы захотите посмотреть, как вы собираетесь делать это скользящее окно, некоторые базы данных не слишком благосклонно относятся к удалению большого процента строк.
Также учтите, что вам, вероятно, понадобится какое-то решение, которое может создавать резервные копии этих данных и восстанавливаться после сбоя в разумные сроки.
Я также думаю, что для базы данных такого размера вам могут потребоваться функции в версии SQL Server Enterprise.
http://www.microsoft.com/sqlserver/2008/en/us/compare-std-ent.aspx
Предприятие обычно имеет функции масштабируемости. Я уверен, что это может быть верно и для Oracle.
Существует множество возможных факторов, влияющих на ответ, и без дополнительной информации трудно дать окончательный ответ. Примерами этих факторов являются источник данных и скорость их записи, частота запросов, простота сегментации и т. Д.
В целом Oracle определенно имеет репутацию, которая лучше справляется с большими нагрузками и может работать на более мощном оборудовании, чем SQL Server.
Однако я думаю, что для больших объемов, как вы описываете, было бы разумно также рассмотреть другие варианты, если ваша организация не требует использования только этих двух продуктов.
Вероятно, вам лучше взглянуть на «экзотический» продукт базы данных, специально разработанный для обработки таких объемов, например Vertica, или даже рассмотреть нереляционные продукты, предназначенные для больших объемов, которые используются поставщиками облачных услуг, такими как Amazon Elastic Mapreduce и Google. Хранилище данных App Engine. Эти продукты набирают обороты в отраслях, требующих огромных объемов данных, таких как телекоммуникационные провайдеры, отрасль финансовых услуг и телематика.
Вы не упомянули, будете ли вы использовать эту базу данных для обработки онлайн-транзакций или для дополнительных хранилищ данных, бизнес-аналитики. Определенно есть несколько специально разработанных вариантов для обоих. Терадата приходит на ум, например, для обработки очень больших объемов данных для BI.
Я не могу говорить о «5-6 ТБ данных», но в настоящее время у меня есть 1700 постоянных пользователей толстых клиентов (приложение, построенное на .NET), работающих с базой данных 1,5 ТБ с использованием 64-битного SQL Itanium.
Он отлично работает. Я думаю, что вопрос масштабирования не столько в размере БД, сколько в количестве пользователей и транзакций в секунду.
Oracle может выполнять кластеризацию для увеличения пропускной способности до количества транзакций в секунду (при определенных обстоятельствах), но я бы не стал предпочитать ни один из них в отношении размера исходной БД.