Какие принципиальные отличия от пошарденного она мильён компутеров key-value хранилища (map[пачка байт:пачка байт]) даёт та данных, которая описана в PDF-доке по BigTable?
BigTable:
RowKey -> ColumnFamily -> Column -> Timestamp -> Value
Ну, например, я хочу сохранить 10 версий ячейки ("mumu" -> "zuzu" -> "abc" -> [0...9] (версии 0...9)).
Почему задачу не решит гора составных ключей вида "mumu,zuzu,abc,0" ... "mumu,zuzu,abc,9"?
Хочешь добавить новую колонку? Добавь ключ "mumu,zuzu,newcolumn,8765432".
И т.п.
Здравствуйте, pkl, Вы писали:
pkl>Какие принципиальные отличия от пошарденного она мильён компутеров key-value хранилища (map[пачка байт:пачка байт]) даёт та данных, которая описана в PDF-доке по BigTable? pkl>Почему задачу не решит гора составных ключей вида "mumu,zuzu,abc,0" ... "mumu,zuzu,abc,9"? pkl>Хочешь добавить новую колонку? Добавь ключ "mumu,zuzu,newcolumn,8765432". pkl>И т.п.
В твоих рассуждениях есть изъян: зачем нужна гора составных ключей, если можно обойтись одним ключом произвольной длины?
Отсюда выходит и ответ: что бы база могла оптимизировать данные согласно из структуры. Bigtable делали с оглядкой на быстрый доступ ко всем столбцам отдельно взятой строки и версионную (с привязкой ко времени) целостность. Поэтому ключ указывающий на стоку имеет физический смысл — эта группа данных, которая должна быть на одном узле или нескольких близких. Равно как и ключ timestamp в некоторых случаях может иметь конкретный физический смысл — версию данных или время их изменения. Отсюда и небольшая специфика адресации.
Здравствуйте, m2l, Вы писали:
m2l>Здравствуйте, pkl, Вы писали:
pkl>>Какие принципиальные отличия от пошарденного она мильён компутеров key-value хранилища (map[пачка байт:пачка байт]) даёт та данных, которая описана в PDF-доке по BigTable? pkl>>Почему задачу не решит гора составных ключей вида "mumu,zuzu,abc,0" ... "mumu,zuzu,abc,9"? pkl>>Хочешь добавить новую колонку? Добавь ключ "mumu,zuzu,newcolumn,8765432". pkl>>И т.п.
m2l>В твоих рассуждениях есть изъян: зачем нужна гора составных ключей, если можно обойтись одним ключом произвольной длины?
m2l>Отсюда выходит и ответ: что бы база могла оптимизировать данные согласно из структуры. Bigtable делали с оглядкой на быстрый доступ ко всем столбцам отдельно взятой строки и версионную (с привязкой ко времени) целостность. Поэтому ключ указывающий на стоку имеет физический смысл — эта группа данных, которая должна быть на одном узле или нескольких близких. Равно как и ключ timestamp в некоторых случаях может иметь конкретный физический смысл — версию данных или время их изменения. Отсюда и небольшая специфика адресации.
Замечание: "mumu,zuzu,newcolumn,8765432" -- один ключ произвольной длины. Не понял про "гору составных ключей".
pkl <99419@users.rsdn.ru> писал(а) в своём письме Sun, 24 Jan 2016 20:36:15 +0500:
> Замечание: "mumu,zuzu,newcolumn,8765432" -- один ключ произвольной длины. Не понял про "гору составных ключей". >
