Дизайн хранилища временных рядов

Я проверил документ временных рядов из облака Google https://cloud.google.com/bigtable/docs/schema-design-time-series, а также дизайн схемы opentsdb, основанный на hbase, который очень похож на bigtable.

Дизайн схемы opentsdb использует множество уловок для кодирования точек данных и ключей строк в широкие строки, чтобы размер каждой точки данных был меньше. Но в статье Google как раз и предлагается использовать узкие строки.

Мой вопрос в том, могу ли я получить реальную выгоду от разработки схемы opentsdb для хранения временных рядов с помощью bigtable. И правда ли, что сжатие bigtable может помочь мне избавиться от избыточности, так что схема opentsdb не имеет большого значения?


google-cloud-bigtable
person Dg3feiko    schedule 01.12.2015    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

Многие из предложений в колоде StumbleUpon и видео MapR (ниже) представляют собой отличные дизайнерские идеи, которые не были включены в документ о временных рядах. Чтобы ответить на ваши вопросы:

  1. Могу ли я получить реальную выгоду от разработки схемы opentsdb для хранения временных рядов с помощью bigtable?

Да, дизайнерские идеи OpenTSDB являются хорошими идеями и совместимы с документом Cloud Bigtable.

  1. Верно ли, что сжатие bigtable может помочь мне избавиться от избыточности, так что схема opentsdb мало что меняет?

Сжатие Cloud Bigtable имеет большое значение. (Маленькие вещи часто сжимаются меньшими, чем большие, даже с избыточностью.)

Схема Дизайн

В документе временных рядов Google есть рекомендации группы инженеров. и имеет многолетний опыт проектирования с Bigtable.

Конечно, вам следует начать с HBase and Schema Design и Разработка схемы для Cloud Bigtable. Магистерская диссертация Яна Варли Никаких отношений: смешанные преимущества нереляционных баз данных тоже стоит прочитать.

Дизайн временных рядов

У Cloudera есть хороший главу, посвященную тематическим исследованиям схем, в которой рассказывается о временных рядах.

Дизайн OpenTSDB

Видео MapR HBase Key Design с OpenTSDB короткое, и его стоит посмотреть. Заглянув в OpenTSDB, можно найти интересную колоду от StumbleUpon.

person Les Vogel - Google DevRel    schedule 02.12.2015
comment
Большое спасибо u @ les-vogel-google-devrel, я проверил приведенные выше ссылки, и они мне очень полезны. Мой вопрос в том, что, хотя HBase и BigTable очень похожи, но небольшая разница может иметь большое значение, например HBase обрабатывает строки с несколькими столбцами или широкие строки намного хуже, чем Cassandra и BigTable, на которые я не могу найти никаких ссылок от Google, чтобы получить некоторые идеи для принятия решений. Еще одна проблема - ключ строки. OpenTSDB изо всех сил старается минимизировать ключ строки, поскольку это повлияет на размер каждой точки данных, но я не знаю, можно ли это применить и к случаю BigTable. - person Dg3feiko; 02.12.2015
comment
Строки большего размера легче отлаживать. Сжатие поможет, но сжатие есть и для коротких клавиш строк. Я бы добавил к ответу user3113571, что если у вас есть все данные в то время, когда вы их пишете, то одна запись будет выполняться быстрее и потреблять меньше ресурсов, чем несколько. Опять же, все сводится к вашему конкретному приложению. Если все ваши данные поступают асинхронно и вы обращаетесь только к одному датчику за раз, тогда узкие строки имеют большой смысл. На самом деле вам не нужно писать одну и ту же строку несколько раз, чтобы сделать ее широкой (для большинства приложений) - в этом нет особого преимущества. - person Les Vogel - Google DevRel; 03.12.2015

arrow_upward
0
arrow_downward

В техническом документе - Дизайн схемы Cloud Bigtable для данных временных рядов - мы рекомендуем узкие ряды по трем причинам.

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

Вторая перспектива характерна для Cloud Bigtable. Мы рекомендуем узкие строки, потому что, если вы используете широкие строки, особенно строки, содержащие потенциально неограниченное количество событий, вы можете легко или неожиданно столкнуться с максимальный рекомендуемый размер строки для Cloud Bigtable 100 МБ, что может привести к проблемам с производительностью.

Третья точка зрения заключается в том, что Apache HBase и Cloud Bigtable - это разные реализации интерфейса HBase. Оптимизация, которая хорошо работает для Apache HBase, может не работать для Cloud Bigtable и наоборот. В этом техническом документе излагаются уроки, извлеченные внутри компании за годы работы с Bigtable в Google, где обычно выясняется, что узкие строки превосходят широкие строки.

Отличный вопрос, глубокий и актуальный, спасибо, что задали его.

person user3113571    schedule 02.12.2015
comment
Спасибо @ user3113571. Что касается второй точки, во многих случаях объем данных предсказуемо фиксирован, например 1 точка данных в секунду и 1 час точек данных на строку. В таком случае лучше использовать широкий ряд, чем узкий? И есть ли какие-нибудь идеи по внутренней оптимизации облачных bigtable, чтобы я мог извлечь из них максимум пользы. Для временных рядов показателей важен каждый байт. - person Dg3feiko; 02.12.2015
comment
Чтобы приблизиться к этому, можно поэкспериментировать с различными схемами и размерами наборов данных, а затем выбрать схему, которая лучше всего подходит для вашего приложения, и интересующие вас метрики. С управляемой службой вы можете полагаться на API и SLA, но не на какие-либо предполагаемые знания. базовой реализации. Cloud Bigtable активно улучшается, и его реализация со временем будет развиваться. Ключевой момент в вашем комментарии - не предполагать, что более широкие строки сохраняют байты, потому что каждый байт имеет значение, экспериментальные результаты - ваш критерий. Спасибо за продолжение. - person user3113571; 03.12.2015