Что мне нужно знать о работе с огромными базами данных?

Question

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

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

Платформа, ориентированные на платформу, тоже будут отличными.

Answer 1

Некоторые идеи

• Узнайте подробности конкретного двигателя базы данных, как он работает

• Как оптимизировать запросы (подсказки, планы выполнения)

• Как настроить базу данных (не только индексы, но и физическое хранение и представление, интеграция ОС).

• Запрос «трюки», такие как временные таблицы для хранения временных результатов, которые можно повторно использоваться,

• Как оценить необходимость денормализации для повышения производительности

• Как использовать инструменты профилирования для базы данных, чтобы идентифицировать узкие места.

Answer 2

Пара советов от производственного DBA (мой опыт - MS SQL, но они должны применяться к другим платформам):

• Техническое обслуживание становится значительный Проблема (ночные резервные копии, DBCCS, еженедельные задания по реиндексу/оптимизации и т. Д.). Очень легко начать превышать разумное ночное или выходное окно обслуживания. Это не просто Технологический проблема, это также бизнес Проблема («Что вы имеете в виду, потребуется 4 часа, чтобы восстановить базу данных из последней хорошей резервной копии?»)

• Разработчики должны понимать, что им может понадобиться работать по -другому. "Ты имеешь в виду, что я не могу просто DELETE (500m rows) FROM MassiveTable И ожидать, что это сработает?

Я уверен, что придумываю больше ...

Answer 3

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

Answer 4

Настоятельно рекомендую прочитать эту презентацию о SQL Antipatternshttp://www.slideshare.net/billkarwin/sql-antipatterns-trike-cack

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

Answer 5

Любые РДБМ могут страдать от плохой производительности, если она становится очень большой, особенно когда используются сложные условия соединения. Схему базы данных должны быть разработаны для масштабирования для большого количества трафика. Большинство систем довольно хороши в обработке нагрузок, но вы также можете столкнуться с проблемами, когда у вас есть одна база данных, которую необходимо распространять по нескольким машинах.

Многие новые инструменты появляются, чтобы справиться с масштабируемостью базы данных. Одним из наиболее многообещающих является Memcached, в котором хранится много данных в памяти, что обеспечивает гораздо более быстрый доступ и СПИД при синхронизации между несколькими серверами баз данных. Некоторые из решений NOSQL, которые дополняют традиционные системы SQL с архитектурами, которые не применяют схемы.

Некоторые примеры технологий NOSQL - Cassandra, Couchdb, Google Bigtable, Mongodb. Некоторые люди клянутся, что эти системы станут решающими для управления «предстоящим взрывом данных».

Answer 6

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

Первый - сложность. Сколько там пользовательских таблиц? Сколько столбцов в этих таблицах? База данных с несколькими сотнями пользовательских таблиц в схеме и более тысячи столбцов в этих таблицах очень сложна. База данных с полдюжины таблиц не очень сложна, даже если она содержит петабайты данных.

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

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

Вот несколько вещей, которые нужно узнать, в дополнение к тому, что уже упоминалось.

Узнайте разницу между разделом таблицы и разложением таблицы. Некоторые люди разлагают таблицы на несколько таблиц с одинаковыми столбцами, когда разделение служит им лучше.

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

(Примечание. Графическая модель часто называют Hiearachical или сетевой моделью).

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