Close

11.08.2017

Новость: У Нас есть SortedMap в AStorage хранилище

Многие знают, что мы — разработчики хранилища ASTorage, которое можно сравнить с распределенным транзакционным Key — Value с управляемой репликацией.

Но теперь AStorage стал ближе к CASSANDRA — внутренняя модель данных дополнилась : у нас появились кластерные ключи! 

Суть , на примерах

Суть примерно такая :

Все знаю, что В Cassandra можно делать «таблицы», хотя реально элементы данных хранятся к ключе — часть в распределительном а часть в кластерном.

Выглядит это примерно так :

partition clustering value
table:foo 111 aaa
table:foo 222 bbb
table:foo 555 ccc
table:foo 888 ccc

Здесь table:foo — распределительный ключ, 111 — кластерный, aaa — значение.

Поскольку у нас теперь все кластерные ключи хранятся последовательно и вместе, для каждой из реплик, то можно запросить а пример следующий \ next ключ

GET /partition/table:foo/clustering/111/next ->
key: 222
value: bbb
version: 2325

Или предыдущий \ prev ключ

GET /partition/table:foo/clustering/222/prev ->
key: 111
value: aaa
version: 24626

 

теперь даже можно запросить диапазон \ range

GET /parition/table:foo?from=111&to=555&limit=1 -> 
[
 key: 222
]

N=3
R=2
W=2

N,R,W — можно не указывать, но если указывать — то одновременно все. т.к. иногда при чтении может происходить «починка данных»- перезапись каких-то реплик, а при записи — сначала надо прочитать текущие версии.

Если не задавать from, то выдача последовательности с самого начала , если не задавать limit — выдаются все записи без ограничений, если не задавать to, то выдача будет до самого конца.

from — не включительно.

to — включительно.

Python клиент (GitHub) будет работать примерно так :

session = Session(..., range_mapper = () -> {})


select(
 partition = ["table", "foo"],
 from = ["111"],
 to = ["555"],
 limit = 2
)

[
 Entry(partiton = ["table", "foo"], clustering = ["111"], value = "aaa"),
 
]


e.next() -> Entry
e.prev() -> Entry

 

Что это позволяет делать

Раньше у нас было только Key-value и DT и каждый ключ распределялся по кластеру. Чтобы строить последовательности нам нужна была цепочка  ключей, или DT, применение которого не везде оправдано (быстрая и гибкая работа с огромными последовательностями, но малая скорость вставки)

Теперь можно строить последовательности, относительно не дорого

предварительные тесты на кластере из 3-х машин со 100МБит/с сетью:

Записей 10_000rps , чтений 50_000rps  для 3-х реплик, 2- кворум).

Это для последовательности с распределенным, консистентным хранением и тремя репликами по плохой сети — великолепные показатели.

batch из таких запросов по каждому распределительному ключу — атомарен. Либо он весь применится, либо не применится весь. В этот batch можно включать операции set, cas — т.е.  проверять версии. Это позволяет оптимистически применять наборы изменений — и реализовывать не блокирующие алгоритмы, однако чтобы это делать по нескольким распределительным ключам — нужны транзакции.

Конечно чтобы этим эффективно пользоваться — надо хорошо проектировать ваши схемы данных.

Транзакции

У нас есть  транзакции поверх Key-Value и поверх DT.

Скоро будут транзакции и поверх этой новой структуры — SortedMap. 

Уже сейчас функционал можно сравнивать с Cassandra.

У нас нет «SQL» , но по удобству использования за счет транзакций ASTorage уже обгоняет C*. Описанный функционал — это и есть, по сути, нижний уровень C*.  Если добавить туда транзакции — победа  будет бесспорной.

 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *