Я хочу знать, какие конкретные проблемы/решения/советы/лучшие практики [не наказывать меня за слово] возникают при работе с огромными базами данных.Что мне нужно знать о работе с огромными базами данных?
Под огромным я подразумеваю базы данных, в которых есть таблицы с миллионами строк и/или баз данных с петабайтами данных.
Платформа-ориентированные ответы также будут отличными.
Некоторые идеи
Узнайте подробности конкретного двигателя базы данных, как это работает
Как оптимизировать запросы (подсказки, планы выполнения)
Как настроить базу данных (не только индексы, но и физическое хранилище и представление, интеграция ОС).
Запрос «трюки», как временные таблицы для хранения временных результатов, которые могут быть повторно использованы,
Как оценить необходимость денормализации для повышения производительности
Как использовать инструменты профилирования для базы данных, для выявления узких мест.
Любая РСУБД может пострадать от плохой производительности, если она становится очень большой, особенно при использовании сложных условий соединения. Схемы баз данных также должны быть рассчитаны на масштабирование для больших объемов трафика. Большинство систем довольно хорошо справляются с нагрузками, но вы также можете столкнуться с проблемами, когда у вас есть одна база данных, которая должна быть распределена между несколькими компьютерами.
Много новых инструментов появляются, чтобы справиться с масштабируемостью базы данных. Одним из наиболее перспективных является Memcached, в котором хранится большое количество данных в памяти, что позволяет значительно быстрее осуществлять доступ и помогает в синхронизации между несколькими серверами баз данных. Некоторые из решений NoSQL, которые дополняют традиционные системы SQL с архитектурой, которые не применяют схемы.
Некоторые примеры технологий NoSQL - это Cassandra, CouchDB, Google BigTable, MongoDB. Некоторые люди клянутся, что эти системы станут решающими в управлении «грядущим взрывом данных».
Моим первым советом было бы нанять кого-то, кто знает, что они делают, и не полагаться на СО, иначе вы могли бы пойти на некоторые чрезвычайно дорогие ошибки. Моей второй будет выбор правильного оборудования и программного обеспечения платформы. Детали будут во многом зависеть от требований.
+1 для найма эксперта домена. Однажды я увидел полезное высказывание со стороны водопроводчика: «Если вы считаете, что нанять профессионала дорого, попробуйте нанять любителя». Это по-прежнему интересный вопрос, с технической точки зрения. –
Несколько советов от производства DBA (мой опыт MS SQL, но они должны распространяться на другие платформы):
обслуживание становится значительной проблемы (ночной резервное копирование, DBCCs, еженедельные задания reindex/оптимизации и т. д.). Очень легко начать превышать разумное окно обслуживания в ночное время или в выходные дни. Это не только техническая проблема, ее также бизнес вопрос («что вы хотите сказать, потребуется восстановление 4 часа для восстановления базы данных из последней хорошей резервной копии?")
Разработчики должны понимать, что им, возможно, придется работать по-другому.« Вы имеете в виду, что я не могу просто DELETE (500m rows) FROM MassiveTable и ожидать, что он сработает?
Я уверен, что я буду думать о более ...
Очень рекомендую вам прочитать эту презентацию о SQL Antipatterns http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back
презентация поможет (да, это мне помогло много) найти решение, казалось бы, тупиковой ситуации.
Существует два аспекта базы данных, которые важнее размера, насколько это касается дизайна и управления.
Первый - это сложность. Сколько таблиц пользователей существует? Сколько столбцов в этих таблицах? База данных с несколькими сотнями пользовательских таблиц в схеме и более тысячи столбцов в этих таблицах очень сложна. База данных с полдюжиной таблиц не очень сложна, даже если она содержит петабайты данных.
Вторая область обмена данными. Если база данных построена для обмена данными между шестью или несколькими приложениями, разработанными отдельными командами разработчиков, вы должны проектировать и управлять ею совсем по-другому, чем база данных, встроенная в одно приложение.
Большинство вопросов о базе данных, заданных в SO, относятся к отдельным базам данных приложений.
Вот несколько вещей, чтобы узнать, в дополнение к тому, что уже упоминалось.
Узнайте разницу между разбиением таблиц и разбиением таблицы. Некоторые люди разлагают таблицы на несколько таблиц с одинаковыми столбцами, когда разбиение будет служить им лучше.
Изучите реальную разницу между графической моделью данных и реляционной моделью данных. Некоторые люди проектируют базы данных, как если бы внешние ключи были по существу такими же, как указатели. То, что у них получается, - это система, которая фиксирует всю медленность реляционной системы и всю неуправляемость графической системы.
(Примечание: графическую модель часто называют гиарохической или сетевой моделью).
Разработка реальной реляционной базы данных гораздо более тонкая и гораздо более полезная, чем проектирование базы данных, которая претендует на то, чтобы моделировать реляционно, но на самом деле смоделирована по графику.
Вы спрашиваете вообще для любой СУБД? Вы можете получить более качественные ответы, задав вопрос о конкретном –
Это также зависит от того, что предназначено для вашей БД? Reporting/Datawarehouse/Transactional и т. Д. – guigui42