Выполнение нескольких соединений

Question

Greetings Overflowers,

Мне нужно запросить объекты со многими / сложными пространственными условиями.В реляционных базах данных это переводится во многие объединения (возможно, 10+).Я новичок в этом бизнесе, и мне интересно, стоит ли использовать MS SQL Server 2008 R2 или Oracle 11g или решения на основе документов, такие как RavenDB, или просто использовать некоторую пространственную базу данных (ГИС) ...

Любые мысли?

С уважением

ОБНОВЛЕНИЕ: Спасибо всем за ответы.Кто-нибудь выберет документ / пространственные базы данных?Моя база данных будет состоять из десятков миллионов записей.В основном только для чтения.Обновлений практически нет, кроме случаев ошибок при вводе.Ночные вставки и не так часто.Таблицы соединений прогнозируются заранее, но количество самостоятельных соединений (таблиц, объединяющихся несколько раз) - нет.Небольшие страницы результатов таких запросов будут просматриваться на интерактивном веб-сайте, поэтому время отклика имеет решающее значение.Любые прогнозы о том, как это может работать на MS SQL Server 2008 R2 или Oracle 11g?Я также обеспокоен повышением производительности за счет добавления большего количества серверов, какой из них лучше масштабируется?Как насчет PostgresQL?

Answer 1

В практическом применении гораздо чаще встречается 10+ объединений с набором таблиц, чем вы думаете. Последствия внутренних и внешних объединений, которые достигают такого высокого уровня, различны, но я бы не стал слишком беспокоиться, если объем данных, по которым вы выполняете внешнее объединение, не станет очень большим. Базы данных оптимизированы для работы с множествами.

Пример:

Буквально вчера я написал запрос, который выполняет 13 внутренних объединений. Он выполняется на 50 000+ записей менее чем за секунду.

Answer 2

Сборка и тестирование.

Это единственный способ узнать, сработает ли ваша идея. Для загрузки доступны бесплатные версии Oracle, SQL Server и Teradata. PostgreSQL бесплатен, точка.

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

Вчера я провел тест (подтверждение концепции) (в моей голове идут вместе дни) на 20 таблицах из 50 миллионов строк, естественных ключах (без идентификаторов), 20 левых объединений, среднее время доступа 40 миллисекунд , Использование стандартного настольного компьютера с медленными дисками и 2 гигабайтами оперативной памяти.

---

Редактировать: Кажется, есть и бесплатная бесплатная версия Greenplum для одного сервера, которая ограничена только двумя сокетами ЦП, без ограничений для ядер ЦП. Никаких ограничений по размеру базы данных тоже нет. Я чувствую необходимость играть с парой терабайт.

Answer 3

И MS SQL Server 2008 R2, и ORACLE 11g должны без проблем справиться с этим. С точки зрения расширяемости, я бы порекомендовал Oracle 11g в среде RAC. Вы также можете выполнять кластеризацию Microsoft с MS SQL Server 2008 R2, но по моему опыту Oracle RAC является более надежным решением.

В то же время приложения, которые вы планируете использовать с базой данных, также должны играть роль в принятии решения. Если вы будете использовать MS SharePoint или другие приложения MS, лучшим решением будет MS SQL Server 2008 R2.

Что касается PostgreSQL, у меня нет особого опыта работы с ним, но я слышал кошмарные истории от людей, которые использовали его в корпоративной среде и в крупных бизнес-ситуациях. Из того, что я знаю, это не совсем подходит для масштабируемости. Лично я думаю, что MySQL будет лучшим решением, чем PostgreSQL, если вы ищете решение с открытым исходным кодом, но имейте в виду, что SQL-решения с открытым исходным кодом не будут самыми легкими, когда речь заходит о масштабируемости или среде высокой доступности, если это ваша конечная цель.

Answer 4

Один из самых больших неизвестных в вашем вопросе - насколько динамичен SQL и для аналогичных операторов SQL, как часто меняются значения в предикатах?Используют ли они параметры связывания вместо встроенных значений (они должны, где это возможно).Если есть много возможностей для повторного использования, Oracle будет моим выбором.

Независимо от сложности SQL, Oracle имеет множество функций, которые могут помочь.Материализованные представления и перезапись SQL могут обеспечить существенное повышение производительности в тех случаях, когда умеренно устаревшие результаты приемлемы по сравнению с результатами в реальном времени.К 11g также добавляется кэширование набора результатов.

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

Answer 5

Согласен, проблема не столько в соединениях, сколько в количестве запрашиваемых данных. Хотя я признаю, что при работе в среде, в которой используются MS SQL Server 2005, MS SQL Server 2008 R2 и ORACLE 10g и 11g, похоже, что наши базы данных MS SQL несколько более подвержены мертвым блокировкам при выполнении больших запросов.