Практический Пример Bigtable
может ли кто-нибудь предоставить реальный пример того, как данные будут структурированы в Bigtable? Пожалуйста, поговорите с поисковой системой, социальной сетью или любой другой знакомой точкой зрения, которая ясно и прагматично иллюстрирует, как комбинация строк -> семейство столбцов -> столбец превосходит традиционные нормализованные реляционные подходы.
2 ответов
чтение оригинальной белой книги Google было полезно:
Как и этот полный список источников информации об архитектуре данных Google:
http://highscalability.com/google-architecture
обновление: 11/4/14
новая версия Google white paper PDF может можно найти здесь:
http://static.googleusercontent.com/media/research.google.com/en/us/archive/bigtable-osdi06.pdf
я считаю, что разница заключается в том, как данные запрашиваются, а не как они хранятся.
основное различие между реляционными базами данных и NoSQL
это значит, что нет SQL
в последнем.
это означает, что вы (а не оптимизатор запросов) пишете планы запросов самостоятельно.
это может увеличить производительность запроса, если вы знаете, как это сделать.
рассмотрим типичный запрос поисковой системы: найти top 10
страницы со всеми (или некоторыми) словами, включенными, скажем, "конкурс мокрой футболки", упорядоченный по релевантности (мы оставляем близость слова в стороне ради простоты).
для этого вам нужно, чтобы все слова разделялись и хранились в поисковом и итерационном списке, упорядоченном (word, relevance, source)
. Затем вы разделяете этот список на (3 * ranks)
наборы (каждый, начиная с верхней части слов в поисковом запросе в заданном ранге), где ranks
- это возможное число рядов или, скажем, 1
to 10
; и присоединиться к наборам на source
, .
в реляционной базе данных это будет выглядеть так:
SELECT w1.source
FROM ranks r1
JOIN words w1
ON w1.word = 'wet'
AND w1.rank = r1.value
CROSS JOIN
ranks r2
JOIN words w2
ON w2.word = 'shirt'
AND w2.rank = r2.value
AND w2.source = w1.source
CROSS JOIN
ranks r3
JOIN words w3
ON w3.word = 'contest'
AND w3.rank = r2.value
AND w3.source = w1.source
ORDER BY
relevance_formula (w1.rank, w2.rank, w3.rank)
LIMIT 10
это лучше всего выполняется с помощью MERGE JOIN
над тремя наборами, разделенными по рангу.
однако ни один оптимизатор, о котором я знаю, не построит этот план (оставляя в стороне тот факт, что relevance_formula
не может распределяться по отдельным рангам).
чтобы обойти это, вы должны реализовать свой собственный план запроса: начните с верхней части каждой пары слово / ранг и просто спуститесь все три набора одновременно, пропуская отсутствующие значения и используя search
а то next
если вы чувствуете, что там будет слишком много, чтобы пропустить в одном из наборов.
таким образом, реляционный подход дает вам более удобный способ запроса данных за счет возможного штрафа за производительность.
если вы разрабатываете веб-сервер кампуса, то написание этих SELECT *
в порядке, даже они выполняются на одну микросекунду дольше, чем они могли бы быть. Но если вы развиваетесь Google, стоит потратить некоторое время на оптимизацию запросов (которые чистые реляционные системы позволяют только доступ к своим данным с помощью SQL
просто не дал бы сделать).
такое называется NoSQL
и реляционные базы данных иногда диффундируют друг в друга. Например, Berkeley DB
известный NoSQL
механизм хранения, который использовался MySQL
в качестве хранилища, чтобы позволить SQL
запросы. И наоборот, HandlerSocket
позволяет чисто запросы ключ-значение к реляционному InnoDB
магазине MySQL
база данных построена над ним.