The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Первый стабильный выпуск отказоустойчивой СУБД CockroachDB, opennews (ok), 11-Май-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


55. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от anonymous (??), 12-Май-17, 17:53 
люди подскажите чем вы пользуетесь для хранения пусть просто key-value, но гарантированного хранения с записью на диск (возможно с одновременной синхронной записью на slave, хотя по идее можно просто хранить на raid) и масштабированием (подключением/отключением/ребалансировкой серверов без brain split как у всяких cassandra/riak).

что вы используете? SQL со своими сложными костылями для шардинга?
mongodb с шардингом из коробки? что-то еще?

Ответить | Правка | Наверх | Cообщить модератору

76. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от нах (?), 14-Май-17, 15:30 
осспадя - да nosql-ей - мильен с тыщами, не монгой единой.
кто что осилил, тем и пользуется, и не факт что это что-то надо тебе. (отдельный вопрос, а как ты чисто теоретически себе представляешь масштабирование _записи_. Не то чтоб было совсем никак, но есть, хм, сомнения в понимании явления.)

В китайской штуке интересного-то только то, что она НЕ key-value, случай редкий, а чтоб еще и табличный формат - так вообще уникальный.
Буквально в марте я пытался что-то похожее нарыть среди опенотсосного софта - хрен там, либо кривое все до омерзения, либо на сложные случаи не рассчитано вовсе (патамушта все остальное ее изобретатели таки да, в sql с кучей подпорок складывают)

note: китайская штука вроде бы совсем не позиционируется как надежное _хранилище_, то есть это совсем не твой случай.

Ответить | Правка | Наверх | Cообщить модератору

77. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –2 +/
Сообщение от Zver (??), 14-Май-17, 15:52 
Да вот как раз позиционируется как strongly-consistent ACID. И я не про НоСКУЛ, про то что его можно масштабировать как тот же Монго и в то же время это SQL со строгой консистентностью данных и наличием транзакций. Для финансов может и не пойдет, но для остального выглядит не плохо, особенно для любителей хоть какой-то надежности и старперов SQLщиков, при том, что в дальнейшем можно будет масштабировать.


Ответить | Правка | Наверх | Cообщить модератору

79. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от пох (?), 15-Май-17, 00:33 
> Да вот как раз позиционируется как strongly-consistent ACID.

я нарочно подчеркнул - надежность _хранения_. То есть она strongly от разваливания, а не от потери данных нафиг - если я правильно угадываю, для чего байде такая хреновина, они могут себе позволить иногда что-то потерять, это не деньги.
А раз у тебя сразу речь про локальные рейды - значит, это не тот случай.

(впрочем, с mysql'ем тоже теряется, не смотря на все системы подпорочек и костыликов)

> И я не про НоСКУЛ

ну здрасьте, кто начал с key-value? Это как раз типичная nosql задача (хотя и есть мнения экспертов, что оно всегда вылазит потом боком). Но вот с надежностью _хранения_ у nosql'ей обычно беда-беда.
(монга песня отдельная, но это и не голая key-value, они себя считают document database, и там в общем все нормально с консистентностью и транзакциями, главное в один непрекрасный день не понять, что ты в их модель данных внезапно не укладываешься и нужно что-то, что умеет join ;)

Ответить | Правка | Наверх | Cообщить модератору

80. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от Zver (??), 15-Май-17, 04:35 
>> Да вот как раз позиционируется как strongly-consistent ACID.
> я нарочно подчеркнул - надежность _хранения_. То есть она strongly от разваливания,

Соответствие ACID подразумевает сохранность данных после завершения транзакции. А не защиту от разваливания.

> ну здрасьте, кто начал с key-value?

Я вообще ничего не говорил про key-value.

В Монге с консистентностью нормально только внутри документа.

Ответить | Правка | Наверх | Cообщить модератору

81. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от лютый жабист__ (?), 15-Май-17, 07:49 
> В Монге с консистентностью нормально только внутри документа.

При этом надо учитывать, что "документ" в Монге это аналог слепленных в РДБМС join-ом n таблиц. Итого консистентность есть и отличная, плюс клёвые фишки в духе fineOneAndDelete и подобное.

Ответить | Правка | Наверх | Cообщить модератору

82. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от пох (?), 15-Май-17, 09:06 
>> В Монге с консистентностью нормально только внутри документа.
> При этом надо учитывать, что "документ" в Монге это аналог слепленных в
> РДБМС join-ом n таблиц.

скорее аналог ненормализованной таблицы. Если бы этим все и ограничивалось, монга была бы ненужна. Храни точно такую же в sql, кто не дает. Я когда-то и пострашнее видел - (oid integer, data blob). Иффсе. Вся база. sql не возражал. На жабке было, кстати, написано, хехехе. Ентерпрайсной.

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

Ответить | Правка | Наверх | Cообщить модератору

83. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от anonymous (??), 15-Май-17, 10:05 
>как ты чисто теоретически себе представляешь масштабирование _записи_

я делал такие костыли поверх SQL и даже свою сетевую файловую систему писал, но хочу знать как это делают другие и что используют. как делал я: берем хеш от ключа (это дает нам нормальное распределение) далее берем его младшие биты и используя младшие биты в качестве индекса в массиве понимаем на каком сервере хранится ключ. это простой вариант, в сложном мы по битам понимаем в каком чанке хранится ключ, а далее узнаем на каком сервере хранится чанк. это именно масштабирование записи и до кучи и чтения. но приходится изобретать свою сложную обвязку на чтение и на запись если нужно перемещение ключей (решардирование) online.

мне сейчас нужно создать масштабируемую систему и либо я сейчас буду опять с нуля писать мегахитрые костыли поверх SQL либо возьму что-то уже готовое. нужно хотябы хранилище ключ-значение которое бы всегда сохраняла ключ на диск прежде чем сказать что оно его записало, чтобы сервера туда легко добавлялись и удалялись и данные на серверах перераспределялись и чтобы brain split не было из за всяких выборов/перевыборов как в cassandra/riak

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

84. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от пох (?), 15-Май-17, 12:14 
> мне сейчас нужно создать масштабируемую систему и либо я сейчас буду опять с нуля писать
> мегахитрые костыли поверх SQL либо возьму что-то уже готовое.

при таком раскладе я бы скачал китайский код, и начал его читать - не в плане как они это сделали, а в плане - я смогу это _сам_ без помощи китайцев поддерживать и менять в нужную мне сторону, или оно так написано что ну его нафиг.
Потому что поддерживать и менять в такой постановке задачи все равно придется. А тут за тебя, зато, китаец цельный облачный sql написал.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру