Практический Пример Bigtable

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

12
bigtable

2 ответов

чтение оригинальной белой книги Google было полезно:

http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/en//papers/bigtable-osdi06.pdf

Как и этот полный список источников информации об архитектуре данных 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

7

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

основное различие между реляционными базами данных и 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 база данных построена над ним.

4