Высокая доступность и дизайн базы данных - PullRequest
2 голосов
/ 02 мая 2011

Это один из вопросов, которые у меня в голове надолго. Как Facebook или любой такой веб-сайт / приложение, которое имеет более ста миллионов пользователей, ведет свою базу данных?

Я считаю, что все нельзя поместить в одну базу данных. Если это так, должно ли быть несколько баз данных, обрабатывающих разные разделы? Различные разделы, такие как: одна база данных для статуса, одна для фотографий и одна для пользователей ...

Можно ли сделать схему базы данных реляционной?

500 миллионов + пользователей и растут, если в среднем один пользователь имеет 10 текстовых обновлений, 5 миллиардов строк (как минимум), что должно составлять 10% данных, которые фактически обрабатывает Facebook.

Я где-то читал, что Facebook имеет более 1800 экземпляров sql, из которых 800+ являются кэшированными. Должны ли эти экземпляры БД быть идентичными? Как они могут быть разработаны?

1 Ответ

9 голосов
/ 10 мая 2011

Facebook и другие крупные компании, которые имеют огромные базы данных, используют разделение базы данных .

Секционирование - это распределение таблицы по нескольким подтаблицам, которые могут находиться в разных базах данных или серверах, чтобы повысить производительность чтения / записи. Секционирование SQL Server обычно выполняется на уровне таблиц, а база данных считается секционированной, когда группы связанных таблиц распределены. Таблицы обычно разбиты на части по горизонтали или по вертикали .

  1. Горизонтальное разбиение (также известное как sharding ) улучшает общую производительность чтения / записи

    Горизонтальное разбиение предполагает размещение разных строк в разных таблицах. Возможно, клиенты с почтовыми индексами менее 50000 хранятся в CustomersEast, а клиенты с почтовыми индексами, большими или равными 50000, хранятся в CustomersWest. Тогда две таблицы разделов - это CustomersEast и CustomersWest, хотя для обоих клиентов может быть создано представление с объединением, чтобы обеспечить полное представление всех клиентов.

    Горизонтальное разбиение - это принцип проектирования базы данных, при котором строки таблицы базы данных хранятся отдельно, а не разбиваются по столбцам (как для нормализации). Каждый раздел является частью сегмента, который, в свою очередь, может находиться на отдельном сервере базы данных или в физическом местоположении.

    У этого подхода к разделению есть множество преимуществ. Общее количество строк в каждой таблице уменьшается. Это уменьшает размер индекса, что обычно повышает производительность поиска. Осколок базы данных может быть размещен на отдельном оборудовании, а несколько сегментов могут быть размещены на нескольких компьютерах. Это позволяет распределять базу данных по большому количеству машин, что означает, что производительность базы данных может быть распределена по нескольким машинам, что значительно повышает производительность. Кроме того, если осколок базы данных основан на некоторой реальной сегментации данных (например, европейские клиенты против американских клиентов), тогда можно будет легко и автоматически вывести соответствующее членство в разделе и запросить только соответствующий фрагмент.

    На практике осколок гораздо сложнее, чем этот. Хотя это было сделано в течение длительного времени ручным кодированием (особенно там, где строки имеют очевидную группировку, как в примере выше), это часто негибко. Существует желание поддерживать автоматическое разбиение как с точки зрения добавления поддержки кода для него, так и для идентификации кандидатов, которые должны быть выделены отдельно.

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

    Осколки по сравнению с горизонтальным разделением

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

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

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

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

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

    Очевидно, что существует также необходимость в некотором механизме уведомлений и репликации между экземплярами схемы, чтобы нераздельные таблицы оставалисьсинхронизированы так, как требует приложение.Это сложный выбор в архитектуре сегментированных систем: подходы варьируются от обеспечения эффективного доступа только для чтения (обновления являются редкими и пакетными), до динамически реплицируемых таблиц (за счет уменьшения некоторых преимуществ распределения сегментирования) и многих вариантов.между ними.

  2. Вертикальное разбиение улучшает доступ к данным

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

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


Влияние на схемы реляционных баз данных

Sharding действительно разрушает вашу реляционную базу данных - что хорошо.Идея шардинга заключается в том, чтобы распределять данные по нескольким базам данных на основе определенных критериев.Это может быть, например, первичный ключ.Все сущности, ключи которых начинаются с 1, переходят в одну базу данных, со 2 - в другую и т. Д. (Часто используются функции по модулю для ключа или группы, основанные на бизнес-данных, таких как местоположение клиента или функция).Существует несколько причин для разделения, основные две из которых - повышение производительности и снижение влияния сбойных баз данных - сбой базы данных затронет только людей с именем, начинающимся с S.

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

  1. Запросы построения графа данных: с их помощью вы получаете свои данные из базы данных, клиентов вместе с адресами и т. Д.

  2. Агрегирование запросов: сколько заказов было сохранено в августе, агрегированных по категориям продуктов

  3. Поисковые запросы: дай мне всех клиентов, которые живут в Нью-Йорке

Sharding теперь устраняет второй и третий запрос и сокращает базы данных до хранилища данных. Поскольку осколки - это разные базы данных в разных системах, вы не можете объединять запросы (по сравнению с кластером) без специального кода в разных системах и не можете выполнять поиск по одному запросу (только по нескольким - по одному для каждой базы данных). Базы данных привели к мысли, что поиск и поиск связаны между собой и должны рассматриваться вместе. Большинство людей считают поиск и поиск одним и тем же. Это заблокировало развитие технологий. Sharding, S3, Dynamo, Memcached недавно изменили эту концепцию. Рикард из Qi4j славы сказал это:

Сущности действительно крутые. У нас есть решил отделить хранилище от индексирование / запросы, вроде как интернет работает с сайтами против Google, что позволяет реализовать действительно простые хранилища. Не приходится иметь дело с запросами делает все намного проще.

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

Люди говорили о разделении памяти и поиске в течение некоторого времени. Поисковые системы, такие как Lucene, вывели поиск из баз данных Но в основном это понятие магазина и поиска. Sharding как механизм для повышения производительности и снижения рисков переместится во многие веб-компании и превратит базы данных в механизм хранения и отбросит агрегацию (хранилище данных и отчетность) и поисковые части. Они могут быть лучше заполнены реальными серверами хранилищ данных, такими как Mondrian, и поисковыми сервисами, основанными на Lucene, или семантическими системами, такими как Sesame. И хранилище может перейти от реляционных баз данных к простым хранилищам, таким как Amazon Simple DB или JDBM или NoSQL.

...