Amazon’s Highly Available Key-value Store

[Сабина]

Меня еще в одном месте удивил вопрос про размер микросервиса в килобайтах. Даже тебе не в гигабайтах, а в килобайтах . Спрашиваю, а почему это так важно ? А вот де AWS чарджит столько что мало не покажется. Что неужели все так плохо и критично ? У нас один из умнейших коллег с прошлой работы ушел в Амазон и написал следующие слова: " I am very depressed that I wasted so many years in ... surrounded by idiots and politics and being forced to write and support garbage while other engineers at places like Amazon, Apple, Google are inventing new technologies. "
Так что же получается это все за наш счет ? В смысле что нам теперь как хочешь - но напиши микросервисы чтобы все не больше среднего и по пять копеек ?

[Сабина]

best practices and pitfalls of building software on top of AWS

Я так поинмаю можно просто шпарить по списку
http://12factor.net/" onclick="window.open(this.href);return false;

[Леонид Ильич Брежнев]

Ставлю на .... Mongo в перспективе 5 лет.

Монго проигрывал, например, Аэроспайку еще год - два назад, как Москвич 401 современному мерседесу.

Ув Леонид Ильич, не удачное сравнение.
Мерседес получше и нынешней лады, а народ в россии почемуто за ладу голосует ногами.
На рынке не всегда властвует тот у кого продукт лучше.
Есть еще такие показатели как community, Q&A на stackoverflow, production installations, (цена иногда).
Вот риак за кое что хочет денег, не важно за что, но где гарантия что ценовая политика не изменится,
как у GoogleAppEngine, спустя 3 года. Или тот же Аэроспайк, попробуйте найти ресурс на рынке с опытом Аэроспайк vs Монго.
Я тут не пытаюсь доказать какая бд лучше. Основной показатель лично для меня это рынок работ и зарплат.

Представьте, что Вам нужно сделать машину, которая не просто будет ездить хуже/лучше по сравнeнию с другими, а которая проезжает США за 5 часов. От побережья до побережья. Потому, что за 6, 7, etc уже не надо. Совсем. И тогда вам уже без разницы сделана машина из желeза от банок для пива или уникальной смеси вольфрама-с-жигулевским. Другое, дело, что за 5 часов кост-ту-кост не всем надо. А если надо, то тогда монго выкидывается и покупается аэроспайк.

[Леонид Ильич Брежнев]

Casandra не потдерживает siblings и только стратегия LWW.

Кассандру можно отрегулировать от eventual consistence до strong consistence. A когда читаю МЛ, я как раз (гибкость в этом плане) кассандры и привожу в пример.

[Леонид Ильич Брежнев]

По поводу multi-dc в cassandra все не так гладко, но так как я ее не использовал не буду дальше голословить. Мое понятие базируется на фитбеке знакомых которые cassandra активно юзают.

Проблема скорее cross ring трафик (дорого и долго), чем сама по себе функциональность.
Внутри одного рэка, грубо говоря, два "логических" DC будут функционировать не хуже чем если бы это был один DC.

[Леонид Ильич Брежнев]

Меня еще в одном месте удивил вопрос про размер микросервиса в килобайтах. Даже тебе не в гигабайтах, а в килобайтах . Спрашиваю, а почему это так важно ? А вот де AWS чарджит столько что мало не покажется. Что неужели все так плохо и критично ? У нас один из умнейших коллег с прошлой работы ушел в Амазон и написал следующие слова: " I am very depressed that I wasted so many years in ... surrounded by idiots and politics and being forced to write and support garbage while other engineers at places like Amazon, Apple, Google are inventing new technologies. "
Так что же получается это все за наш счет ? В смысле что нам теперь как хочешь - но напиши микросервисы чтобы все не больше среднего и по пять копеек ?

Понятное дело, что и Амазон и любой иной WS заинтерсован, что бы трафика ходилo меньше. Это и деньги и нагрузка на web server (отрытые ресурсы). У тех из AWS, кто провайдит данные (а не исполнение) есть обычно ограничения, например у SimpleDB он был, если мне не изменяет память 1 мег на максимум размера страницы ответа.
p.s. при чем тут правда микросервисы?

[kostik78]

Кассандру можно отрегулировать от eventual consistence до strong consistence. A когда читаю МЛ, я как раз (гибкость в этом плане) кассандры и привожу в пример.

Как я уже написал выше - siblings и eventual/strong consistency мягко говоря не совсем одно и тоже

Проблема скорее cross ring трафик (дорого и долго), чем сама по себе функциональность.
Внутри одного рэка, грубо говоря, два "логических" DC будут функционировать не хуже чем если бы это был один DC.

То есть Вы говорите что в случае deploy on multisite ring будет шариться между обоими DC? бррр, надеюсь хоть там используется fast paxos или raft. И если то что я написал выше про read will fail when cluster is unstable как то выглядит совсем кисло Или я что-то пропускаю ?

[Сабина]

Понятное дело, что и Амазон и любой иной WS заинтерсован, что бы трафика ходилo меньше. Это и деньги и нагрузка на web server (отрытые ресурсы). У тех из AWS, кто провайдит данные (а не исполнение) есть обычно ограничения, например у SimpleDB он был, если мне не изменяет память 1 мег на максимум размера страницы ответа.
p.s. при чем тут правда микросервисы?

просто речь шла о микросервисах и товарищ волновался что если один апп расщепить на много микросервисов - хостить в облаке влетит в копеечку. Но я перый раз слышу чтобы размер of deployed app так досконально и скрупулезно мерялся

[Леонид Ильич Брежнев]

Как я уже написал выше - siblings и eventual/strong consistency мягко говоря не совсем одно и тоже
То есть Вы говорите что в случае deploy on multisite ring будет шариться между обоими DC? бррр, надеюсь хоть там используется fast paxos или raft. И если то что я написал выше про read will fail when cluster is unstable как то выглядит совсем кисло Или я что-то пропускаю ?

Да, я видел, сиблинка в Кассандре нету, их схема в этом плане проще. В остальном Кассандра безусловно tunable от ничего не гарантируем до "вот тебе крест". У кассандры есть регулировка избыточности, так что при определенном уровне падения она будет гарантировать и read и write, но если продолжать падать то только write, a пором уже и вовсе ничего . Это нам на Политбюро приходили рассказывали.
Что касается второго вопроса, то возможно мы понимаем задачу по разному, но чудес ведь не бывает, если есть cross ring traffic: primary DC у Политбюро в Москве, а secondary DC на Камчатке. И если read/write идут только в Москву, то делать репликациюи Москва => Камчатка (в одну сторону) всегда будет проблемой для высоконагруженных систем. Решений два: либо мы позволяем read/write и в Москве и на Камчатке с минимальной репликацией Москва <=> Камчатка (плохо, но как вариант), либо делаем как в AWS, ring в Москве - это ring в Москве (Кремль, Дом Правительства, Совет Федерации), a ring на Камчатке - это ring на Камчатке (сопка раз, сопка два, сопка три). Ринги друг к другу отнощения не имеют, реплицируются строго внутри себя.

[Леонид Ильич Брежнев]

p.s. при чем тут правда микросервисы?

просто речь шла о микросервисах и товарищ волновался что если один апп расщепить на много микросервисов - хостить в облаке влетит в копеечку. Но я перый раз слышу чтобы размер of deployed app так досконально и скрупулезно мерялся

Я не очень понимаю, что такое микросервис по отношению к Амазона.
Ну кроме советского, не цензурного, простите анекдота:

Встретились двое. Один обращается к другому:
- Федя, ты слышал, что люди говорят? Доллар-то падает!
- Вася! Да чтобы у тебя х....й так стоял, как он падает.

[Сабина]

Я не очень понимаю, что такое микросервис по отношению к Амазона.

А я то что с этим сделаю ?
Своими словами не донесла, видеоквоты СТО Амазона тоже не помогли. Как мне еще обьяснять ?
Ну вот идете вы на страничку, выбираете товар и жмете кнопицу, а на бакенде в это время сотни микросервисов шуруют.

[Леонид Ильич Брежнев]

Ну вот идете вы на страничку, выбираете товар и жмете кнопицу, а на бакенде в это время сотни микросервисов шуруют.

[Сабина]

Кстати для всех не любителей noSQL, вот пример из соседнего раздела of a very high throughput scalable системы построенной на Postgres
https://blog.cloudflare.com/scaling-out ... g-citusdb/" onclick="window.open(this.href);return false;
Конечно подходит под специфичные нужды как обычно, но use case в общем то распространенный. Citus DB is the keyword.

Всё равно джойны надо убирать по возможности, архитектуру менять в сторону декаплинга и денормализации, но можно и two phase commit если очень охота
Тут все подробно рассказывают и показывают - https://www.youtube.com/watch?v=mbXPbLjiYTI" onclick="window.open(this.href);return false;

[kostik78]

У кассандры есть регулировка избыточности, так что при определенном уровне падения она будет гарантировать и read и write, но если продолжать падать то только write, a пором уже и вовсе ничего . Это нам на Политбюро приходили рассказывали.

Нее ... погодите что-то тут не сходиться. Давай те на кошечках Представим что у нас 3 сервера и ring распределен так (раcсматриваем только primary replicas)
server 1 - ring part A
server 2 - ring part B
server 3 - ring part C

Насколько я понял из приведенного мной фрагмента сравнения Riak and Cassandra в случае выпадания server 1 из кластера, Cassandra будет отклонять чтения данных которые являются частью ring part A, part B & C останутся не тронутыми. Я правильно понял или нет? Если все так, то мой комент про существенные ограничения которые нужно учитывать остается в силе, иначе нет

[valchkou]

Вот тут такое на cassandra брешут. Это правда ?

In the event of server failures and network problems, Riak is designed to always accept read and write requests, even if the servers that are ordinarily responsible for that data are unavailable.

Cassandra will allow writes to (optionally) be stored on alternative servers, but will not allow that data to be retrieved. Only after the cluster is repaired and those writes are handed off to an appropriate replica server (with the potential data loss that timestamp-based conflict resolution implies, as discussed earlier) will the data that was written be available to readers.

При некоторых настройках consistency - да.
важно понимать что write request попросту ставится в очередь, сам write не случается, потому и данные недоступны.
Это как раз особенность кассандры что она не держит данных где попало,
так как в кассандре Data Replication & Data Distribution - это одно и то же.
потому стоит внимательно подойти к конфигурации кластера, чтобы минимизировать риск таких ситуаций.

Допустим у нас 3 Nodes и ReplicationFactor=3 (каждая нода держит копию)
Как будет работать write с разным Consistency:
СL: ALL - all 3 nodes should reply success. - если хоть одна из 3-х недоступна write fails
CL: QUORUM - 2 nodes should reply success - 2 из 3х должны быть доступны
CL: ONE - 1 nodes should reply success
CL: ANY - 1 любая. Для данного случая сработает вышеупомянутый hinted handoff.

А теперь допустим одна из нод недоступна и запись прошла с CL: QUORUM. 2 копии успешно сохранены.
Допустим эти данные считывают 2 клиента.
Один считывает с consistency QUORUM или ниже, а другой ALL.
Так вот тот который ALL - данных не получит, несмотря на то что 2 копии имеются в БД

Конечно все это нужно учитывать.
NoSQL вообще желательно сначала изучить инструмент досконально и понять насколько он подходит под требования,
прежде чем его использовать. К сожалению у руководства не всегда есть желание выделить ресурсы на изучение, прототипы.

Представьте, что Вам нужно сделать машину, которая не просто будет ездить хуже/лучше по сравнeнию с другими, а которая проезжает США за 5 часов. тогда монго выкидывается и покупается аэроспайк.

Ув Леонид Ильич, согласен с тобой полностью, когда есть жесткие требования, с ограниченым бюджетом, то задача по выбору правильного инструмента упрощается.

[kostik78]

...

А теперь допустим одна из нод недоступна и запись прошла с CL: QUORUM. 2 копии успешно сохранены.
Допустим эти данные считывают 2 клиента.
Один считывает с consistency QUORUM или ниже, а другой ALL.
Так вот тот который ALL - данных не получит, несмотря на то что 2 копии имеются в БД

Если это работает так как Вы указали то поведение эквивалентно Riak. Нужно мне тут поразбираться, потому что Basho говорит что это не так, да и знакомые говорят что не так. Говориться что Cassandra не даст читать сегмент данных если primary replica для которых недоступна.

[valchkou]

Если это работает так как Вы указали то поведение эквивалентно Riak. Нужно мне тут поразбираться, потому что Basho говорит что это не так, да и знакомые говорят что не так. Говориться что Cassandra не даст читать сегмент данных если primary replica для которых недоступна.

У Cassandra нет понятия primary replica. Все реплики равноценны и все primary, а все ноды - мастер.

[kostik78]

У Cassandra нет понятия primary replica. Все реплики равноценны и все primary, а все ноды - мастер.

Что-то мне подсказывает после Вашего ответа что Вы недоконца понимаете как работает ring

[valchkou]

У Cassandra нет понятия primary replica. Все реплики равноценны и все primary, а все ноды - мастер.

Что-то мне подсказывает после Вашего ответа что Вы недоконца понимаете как работает ring

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

[kostik78]

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

Агааа... то бишь все тоже самое что и в Riak http://www.datastax.com/dev/blog/modern-hinted-handoff" onclick="window.open(this.href);return false;
Разница только в одном как сделана MDC. В Riak это независимые кольца, в Cassandra шареный. То бишь в MDC деплойменте время реакции на failure в Cassandra выше и потенциальный data loss при eventual consistency ввиду отсутсвия siblings. Теперь понятно стало

[Сабина]

Насколько я понял из приведенного мной фрагмента сравнения Riak and Cassandra в случае выпадания server 1 из кластера, Cassandra будет отклонять чтения данных которые являются частью ring part A, part B & C останутся не тронутыми. Я правильно понял или нет? Если все так, то мой комент про существенные ограничения которые нужно учитывать остается в силе, иначе нет

Я тут учу что и Кассандра и Риак - они оба АР из САР теоремы . Получается один ограниченнее другого но по сути похоже?

[kostik78]

Я тут учу что и Кассандра и Риак - они оба АР из САР теоремы . Получается один ограниченнее другого но по сути похоже?

Да нее ... разобрались уже ... одно и тоже почти одно и тоже. В Riak есть siblings

[valchkou]

Я тут учу что и Кассандра и Риак - они оба АР из САР теоремы . Получается один ограниченнее другого но по сути похоже?

Да нее ... разобрались уже ... одно и тоже

разница в том как данные представлены.
Cassandra - column based and requires schema like in RDBMS
Riak - document based, like MongoDB
+- различные фишки.

[valchkou]

Я тут учу что и Кассандра и Риак - они оба АР из САР теоремы . Получается один ограниченнее другого но по сути похоже?

Да нее ... разобрались уже ... одно и тоже

разница в том как данные представлены.
Cassandra - column based and requires schema like in RDBMS
Riak - document based, like MongoDB
+- различные фишки.

исходя из вышеупомянутого есть огромная разница в UPDATE
Допустим у нас есть объект Person{id, name, phones[] }

Riak follow a read-modify-write cycle when performing updates.
примерно так

Code: Select all

    person = bucket.get(id)
    person.age = 15
    person.name = "kostik78"
    person.phones = [123]
    person.store()
    
    // change name
    person = bucket.get(id)
    person.name = "valchkou"
    person.store()
    
    // add phone
    person = bucket.get(id)
    person.phones = [123, 456]
    person.store()    

Т.е Riak манипулирует объектом как с единым целым

Cassandra не требуется считывать объект прежде чем его модифицировать, так же можно менять индивидуальные проперти.
Приведу пример с mapper + СQL для наглядности.

Code: Select all

    Person person = mapper.get(Person.class, id);  CQL: select * from person where id =id
    person.age = 15
    person.name = "kostik78"
    person.phones = [123]
    mapper.save(person)  CQL: update person set age=15 ... where id=id
    
    // change name. No reads before write
    mapper.setValue(id, Person.class, ''name", "valchkou") 
    CQL: update person set name='valchkou' where id=id
    
    // add phone
    mapper.append(id, Person.class, 'phones', "345") 
    CQL: update person set phones = phones+'345' where id=id

[Kirhist]

На самом деле есть прекрасный опен соупс проект который был создан на основе dinamo - Riak. Написан прекрасной командой из basho(некоторых лично знаю). Продукт довольно стабильный и комьюнити сильное. У нас он пашет тоже только в путь - 2k read requests per server. 32 servers in cluster.

2k read requests - это как-то не очень много... Для Cassandra это даже на разминку не тянет. Хотя конечно зависит от типа запросов...
Соглашусь с обсуждением выше что Riak DB & Cassandra имеют очень схожую архитектуру и функциональность. К нам в контору приходили представители и тех и других, и надо сказать Cassandra team выглядела гораздо уверенней и солиднее. На прямой вопрос про преимущество Riak по сравнению с Cassandra толком ничего не было сказано, кроме как легкость администрирования. Так же смущает отсутствие хороших бенчмарков Riak, да и развивается C* гораздо активнее. Сравнить в продакшин к сожалению не было возможности, работаем пока только с Cassandra и Hadoop.