Уведомление: я возглавляю управление продуктами для Cloud Bigtable.
Если вы не планируете извлекать или обновлять данные с детализацией по столбцам, ваш план хранения документа JSON в виде одного значения подойдет, особенно потому, что если вы храните данные по столбцам, само имя семейства столбцов (и квалификатор ) также необходимо хранить в каждой строке, что увеличивает накладные расходы на хранилище, которые пропорциональны количеству значений и, следовательно, могут иметь значение в вашем масштабе. В своей модели вы будете использовать Bigtable просто как хранилище ключей и значений.
Если вы все же решите разбить JSON на множество столбцов в будущем, вы можете добавить дополнительные семейства столбцов в существующую таблицу Bigtable (или просто использовать дополнительные квалификаторы столбцов в существующем семействе столбцов) и переписать свои данные с помощью параллельного процесса, например Hadoop MapReduce или Google Cloud Dataflow.
Боковое примечание: JSON очень подробный и занимает немного места; хотя вы можете предварительно сжать его самостоятельно, Cloud Bigtable сжимает данные изначально (прозрачно), чтобы помочь смягчить это. Тем не менее, одна из альтернатив, которую следует рассмотреть, - это буферы протокола или другое двоичное кодирование для более эффективного использования пространства. .
Учитывая, что вы планируете хранить несколько петабайт данных, вам, вероятно, потребуется больше, чем по умолчанию квота из 30 узлов Bigtable - в этом случае запросите дополнительную квоту для вашего варианта использования.
Пожалуйста, посетите страницу производительности Bigtable, чтобы получить приблизительную оценку производительности, которую вы должны ожидать от узла сервера Bigtable. , но вы должны сравнить свои конкретные шаблоны чтения / записи, чтобы установить базовые нормы и соответственно масштабировать.
Удачи в вашем проекте!
person
Misha Brukman
schedule
05.07.2016
