почему масштабирование записей в реляционную базу данных практически невозможно? - PullRequest
8 голосов
/ 12 июля 2011

Из слайдов презентации Кассандры (слайд 2) ссылка 1 , альтернативная ссылка :

масштабирование записи в реляционную базу данных практически невозможно

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

Ответы [ 4 ]

6 голосов
/ 12 июля 2011

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

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

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

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

Однако, поскольку логически связанные данные не являются физически смежными, а разбросаны, процесс сбора всех строк в определенном почтовом индексе, скажем, дорогой. Таким образом, эта оптимизация разреженной таблицы hashed-pk является оптимальной только в том случае, когда преобладающим действием является вставка записей, обновление отдельных записей и поиск данных, относящихся к одному объекту за раз, а не к большому набору объектов, как, скажем, в системе ввода заказов. Компания, которая продала товары по телевизору и должна была обслуживать десятки тысяч одновременных заказчиков, размещающих заказы, будет хорошо обслуживаться системой, которая использует разреженные таблицы с хешированными первичными ключами. База данных национальной безопасности, которая опирается на связанные списки, также будет хорошо обслуживаться этим подходом. Многие приложения для социальных сетей также могут использовать его с пользой.

5 голосов
/ 13 июля 2011

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

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

2 голосов
/ 12 июля 2011

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

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

1 голос
/ 13 июля 2011

Это не так. Слайд неправильный (или, по крайней мере, утверждение должно быть более аккуратным при предъявлении такого явно смелого утверждения).

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

...