Оптимальная модель параллелизма для масштабируемых баз данных, индексов?

Question

Мне интересны техники параллелизма, которые относительно просты в реализации и подходят для масштабирования (несколько узлов).

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

надеюсь, эта тема будет полезна другим. спасибо!

обновление

Мне интересны склады и модели nosql.

Answer 1

вам нужно продумать именно то, что вы ищете.«масштабируемый» относится к размеру БД?количество читателей?количество одновременных писателей?пропускная способность читателей в присутствии не конфликтующих по своей сути авторов?под "индексом" вы подразумеваете традиционный полностью упорядоченный индекс, такой как btree, или подойдет хеширование?Кроме того, какой степени согласованности вы хотите достичь среди читателей и писателей?

предыдущий комментарий предлагает хеширование, что отлично, если вам не нужен упорядоченный индекс типа btree именно потому, что операция хеширования разбивает пространство ключей наотдельные части, чтобы избежать одновременных операций.Запросы диапазона, с другой стороны, нуждаются в каком-то индексе дерева, который имеет проблемы, потому что одно обновление может заблокировать все другие запросы, так как оно корректирует индекс.традиционное решение этого http://en.wikipedia.org/wiki/Multiversion_concurrency_control

Answer 2

Идеальный подход для максимизации возможностей параллелизма в базе данных - это использование «малонаселенной» таблицы с хешированным ключом. Это позволяет мгновенно извлекать записи по PK (или суррогату, который может быстро доставить вас к PK) и в значительной степени устраняет конфликты. Нет необходимости читать индекс, чтобы определить, где запись «живет» в таблице, поскольку ее местоположение может быть вычислено из хешированного PK. Тем не менее, при максимизации возможностей параллелизма таким образом вы, вероятно, столкнетесь с некоторым другим компромиссом, таким как неспособность извлечь все записи, скажем, для определенного почтового индекса, или невозможность упорядочить таблицу мгновенно какое-то значение даты. Быстрый выбор всех записей для данного почтового индекса или упорядочение строк по столбцу даты обычно физически группирует эти записи, делая их смежными на диске, чтобы избежать чрезмерного перезаписи диска. В малонаселенной таблице с хешированным ключом может происходить значительное перебивание диска при извлечении групп записей (например, всех клиентов в Нью-Йорке), в то время как при извлечении отдельной записи (клиент № 123456) он превосходит.

РЕДАКТИРОВАТЬ: я должен добавить, что в таких малонаселенных базах данных с хешированным ключом нет ничего необычного в том, чтобы найти составные первичные ключи, такие как ZIPCODE * CUSTOMERNUMBER, чтобы все клиенты в данном почтовом индексе в конечном итоге хранились примерно та же область малонаселенной таблицы; это сделано, чтобы минимизировать побои при запуске отчетов, управляемых почтовым индексом. Таким образом, существуют способы смягчения неблагоприятных последствий этого подхода при сохранении его исключительно низкой частоты столкновений и выборок записей, не требующих индекса.

РЕДАКТИРОВАТЬ2: И скажем, что вы хотели сделать адрес электронной почты PK, и все же не хотели, чтобы записи всех пользователей из AOL, YAHOO или GOOGLE были кластеризованы в одной и той же области запасной таблицы, что привело к "выпирает" там, как анаконда, которая проглотила свинью. Вы можете использовать лево-взвешенный алгоритм хеширования первичного ключа, чтобы сделать больший акцент на значениях слева от @. Но если бы вы использовали числовой последовательный PK, вы могли бы использовать правильный алгоритм для устранения таких выпуклостей.