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

Question

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

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

Ответы, ориентированные на платформу, тоже будут хорошими.

Answer 1

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

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

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

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

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

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

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

Answer 2

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

• Обслуживание становится существенной проблемой (еженедельное резервное копирование, DBCC, еженедельные задания по переиндексации / оптимизации и т. Д.). Очень легко начать превышать разумный ночной или выходной интервал обслуживания. Это не просто техническая проблема, это также проблема business ("что вы имеете в виду, потребуется 4 часа, чтобы восстановить базу данных из последней хорошей резервной копии?" )

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

Уверен, я подумаю еще ...

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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

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

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

Answer 6

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

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

Некоторыми примерами технологий NoSQL являются Cassandra, CouchDB, Google BigTable, MongoDB.Некоторые люди клянутся, что эти системы станут решающими в управлении "грядущим взрывом данных".