The OpenNET Project / Index page

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

Первый стабильный выпуск отказоустойчивой СУБД CockroachDB

11.05.2017 11:50

Состоялся первый стабильный выпуск распределённой СУБД CockroachDB, позволяющей создавать высоконадёжные горизонтально масштабируемые хранилища. При помощи CockroachDB можно развернуть географически распределённые системы, отличающиеся высокой живучестью и не зависящие от сбоев дисков, узлов и даже выхода из строя целых центров обработки данных. Ситуации сбоев обрабатываются автоматически и работа восстанавливается с минимальными задержками. При этом CockroachDB гарантирует целостность ACID-транзакций, предоставляет возможность использования SQL для манипуляции с данными, позволяет вносить изменения в схему хранения на лету, поддерживает индексы и внешние ключи.

CockroachDB разработан под впечатлением от технологий Google Spanner и F1, но в отличие от них является полностью открытым продуктом. Код проекта написан на языке Go и распространяется под лицензией Apache 2.0. Из наиболее подходящих для CockroachDB применений отмечается организация хранения данных приложений, от которых требуется постоянная доступность и целостность данных, а также гибкая масштабируемость (расширение сводится к добавлению новых узлов, которые автоматически включаются в кластер).

CockroachDB предоставляет средства для автоматической репликации, ребалансировки хранилища, обнаружения сбоев и восстановления, при минимальной настройке и обслуживании, что отлично подходит для создания распределённых хранилищ и облачных решений, развёртываемых поверх нескольких центров обработки данных. Система обработки транзакций соответствует требованиям ACID. Обмен данными между узлами производится с использованием шифрования. Аутентификация выполняется на основе SSL-сертификатов. Для клиентов предусмотрена система разделения привилегий. Для приложений предоставляется высокоуровневый SQL API (урезанное подмножество SQL), совместимый с клиентскими драйверами для PostgreSQL.

Из ограничений CockroachDB отмечается плохая пригодность для решений, требующих очень низкого времени отклика при выполнении операций записи и чтения. CockroachDB также плохо адаптирован для нагруженных систем обработки аналитической информации (OLAP), манипулирующих сразу большими срезами данных, и плохо оптимизирован для выполнения сложных SQL-запросов со слиянием нескольких таблиц (JOIN). В версии CockroachDB 1.0 разработчики попытались частично решить проблемы со сложными запросами и представили новый движок распределённого выполнения запросов, допускающий выполнение операций JOIN над данными, распределёнными по разным узлам. Новый движок позволяет добиться линейного ускорения аналитических запросов при добавлении новых узлов в кластер. Новая система уже используется в компании Baidu для обработки БД, расширяющейся примерно на два миллиарда записей в день.

На низком уровне данные хранятся в формате RocksDB (вариант LevelDB) в виде связок ключ/значение с разбивкой на сегменты, охватывающие определённый диапазон данных (по умолчанию размер сегмента - 64MB). После заполнения сегмента данные разбиваются на два новых сегмента, каждый из которых охватывает более узкий диапазон значений, и этот процесс разбиения производится непрерывно. При наличии нескольких узлов образуемые новые сегменты автоматически распределяются на узлы, на которых больше свободных ресурсов. Ребалансировка производится с использованием P2P-протокола gossip, который помогает поддерживать информацию о доступных адресах узлов и состоянии их ресурсов.

Для обеспечения отказоустойчивости данные реплицируются на несколько узлов, на основе которых строится кластер без единой точки отказа, способный работать в режиме multi-active. Для обеспечения непротиворечивости реплик при записи используется метод достижения консенсуса на основе алгоритма Raft. Для обеспечения непротиворечивости операций чтения используется собственный алгоритм синхронизации на основе временных меток. В рамках одной транзакции могут охватываться данные с разных узлов. При репликации данных учитывается топология кластера - дубликаты создаются с учётом обеспечения резервирования разных серверов, стоек и ЦОД.

  1. Главная ссылка к новости (https://www.cockroachlabs.com/...)
  2. OpenNews: Релиз распределенной системы хранения конфигурации etcd 3.1
  3. OpenNews: Facebook открыл код распределённого SQL-движка для петабайтных хранилищ
  4. OpenNews: LinkedIn открыл код распределённого OLAP-хранилища Pinot
  5. OpenNews: Выпуск распределённого хранилища Ceph 10.2.0
  6. OpenNews: Доступна распределённая графо-ориентированная СУБД Dgraph 0.4
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46529-cockroachdb
Ключевые слова: cockroachdb, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (79) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, cmp (ok), 12:58, 11/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –14 +/
    > написан на языке Go

    Задолбали уже, 2 новости про это как всегда не будет.

     
     
  • 2.3, Crazy Alex (ok), 14:03, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да хрен его знает... Если, вон, Байду использует - значит, оно хоть как-то живое и, в общем, вполне заслуживает упоминания.
     
     
  • 3.4, cmp (ok), 14:38, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –14 +/
    Да надо отдельный стрим делать новостей от британских ученых и разрабов на го, я уже настроился почитать, а тут на 2ом обзаце поддых, явы мало блин, надо еще одну тормозную хрень.
     
     
  • 4.5, F (?), 14:44, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Во-первых, надо уметь готовить. Во-вторых, в промышленном использовании Java и Go очень даже ничего смотрятся. А, в-третьих, стоимость сопровождения тоже есть величина интересная.

    Но вы не стесняйтесь, пишите на том, на чем считаете нужным, и что вам кажется быстрым - а мы посмотрим, сравним, покритикуем!

     
  • 4.9, Crazy Alex (ok), 16:03, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    а что там в Go с тормозами?
     
     
  • 5.13, _ (??), 17:09, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не хуже чем у других! (С)   :-)
     
  • 4.11, _ (??), 17:03, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как страшно жить! (С)
    Мучайся, Go взлетел и его вокруг будет только больше и больше.
    (демоническим голосом) Му-ха-ха-хаа! 8-)
     
     
  • 5.30, cmp (ok), 01:12, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, как и ява, 10 15 лет обещают, что она будет сравнима по скорости с СИ и... большой текст свёрнут, показать
     
     
  • 6.33, лютый жабист__ (?), 06:43, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Про жрать меньше памяти - норкоманов не слушай В жабе не ломают совместимость... большой текст свёрнут, показать
     
     
  • 7.34, Аноним (-), 07:25, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Я в своём кругу видел много сишного софта на array-ях, которое мало ело ОЗУ и было НИКАКОЕ по скорости, по сравнению с могучей жабкой на адекватных стурктурах.
    >в своём кругу

    Найдите нормально сишнека и не позорьтесь со своими выводами. Хотя нет, позорьтесь, ява головного мозга не лечится.

     
     
  • 8.36, лютый жабист__ (?), 07:36, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нормальный сишник это такая сущность, которая обитает в Астрале, которая может, ... текст свёрнут, показать
     
     
  • 9.38, Аноним (-), 07:45, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ваш ограниченное окружение вкупе с правильно мнение -- только мое мнение завед... текст свёрнут, показать
     
     
  • 10.39, лютый жабист__ (?), 08:18, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    IBMовские mainframe-ы исполняют сразу жабу У тебя нету мэйнфрэйма Наверное и н... текст свёрнут, показать
     
     
  • 11.41, Аноним (-), 10:34, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Если джава такая замечательная, то почему она написана на тормозном C Совпаде... текст свёрнут, показать
     
     
     
    Часть нити удалена модератором

  • 13.45, cmp (ok), 12:16, 12/05/2017 [ответить]  
  • +/
    Ява быстрее си, ахахаха, тебя псаки покусала или ты с рождения такой ... текст свёрнут, показать
     
     
  • 14.50, Аноним (-), 13:30, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я думаю что он пишет на Си так что у него всегда Java быстрее работает А понять... текст свёрнут, показать
     
     
  • 15.56, лютый жабист__ (?), 20:04, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Пока ты будешь на своём анси си реализовывать хэшмэп, я 50 раз закончу всю прогу... текст свёрнут, показать
     
     
  • 16.60, Аноним (-), 21:42, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Как там говорится, слив защитан Причем тут скорость разработки и скорость ЯП Н... текст свёрнут, показать
     
  • 16.61, Аноним (-), 21:55, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты действительно думаешь что это честное сравнение Ты либо глуn, либо Береш... большой текст свёрнут, показать
     
     
  • 17.67, лютый жабист__ (?), 08:22, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это моя проблема, что в core java есть много плюшек, которых у вас нет Назвался... текст свёрнут, показать
     
     
  • 18.72, Аноним (-), 13:01, 14/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты всегда берешь кассандру без постановки задачи И как связано взятие чего-т... большой текст свёрнут, показать
     
  • 16.65, cmp (ok), 07:13, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да есть готовые, полно, но на 10к элементов они показывают худшие результаты по ... большой текст свёрнут, показать
     
     
  • 17.68, лютый жабист__ (?), 08:24, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    8 прохладны твои былины, бро ... текст свёрнут, показать
     
  • 12.57, Адепт Анонима (?), 20:44, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Никто не спорит, что при грамотной писанине на Си программа будет быстрее и памя... большой текст свёрнут, показать
     
     
  • 13.62, Аноним (-), 22:00, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да, все вроде бы верно, но время Java проходит По инерции еще будет держаться в... текст свёрнут, показать
     
     
  • 14.63, Адепт Анонима (?), 00:12, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Выйграть битву не значит выйграть войну Построение больших систем требует компл... большой текст свёрнут, показать
     
     
  • 15.66, Аноним (-), 08:12, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Прочел вас и вспомнил AT T которая считала рынок и свое положение непоколебимым ... текст свёрнут, показать
     
     
  • 16.71, Адепт Анонима (?), 23:52, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя вы не указали что-то конкретное, я уважаю ваше мнение и думаю, что оно впол... текст свёрнут, показать
     
  • 9.69, Ydro (?), 13:47, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У меня программирование - домашнее хобби, в итоге Сто раз читал книги по Jave -... текст свёрнут, показать
     
     
  • 10.70, Led (ok), 22:47, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сбегай за пивом и Подавай ужин - это не программирование ... текст свёрнут, показать
     
  • 8.51, Вареник (?), 16:29, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кто-то никогда не поймет разницы между небольшим драйвером с одним потоком коман... текст свёрнут, показать
     
  • 6.43, диванный аналитик (?), 11:08, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    В реальном мире программные продукты пишут ради денег. Java позволяет получить достаточно хороший результат в соотношении цена/удобство/скорость разработки/скорость работы. При этом она достаточно безболезненно запускается на разных платформах. В реальном мире всех волнуют лишь деньги, добро пожаловать
     
     
  • 7.48, cmp (ok), 12:34, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В реальном мире программные продукты пишут ради денег

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

     
     
  • 8.52, Вареник (?), 16:32, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поэтому насильники-профессионалы предпочитают средненький но практичный Глок эпи... текст свёрнут, показать
     
     
  • 9.54, cmp (ok), 17:44, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    профессионалы это кто например армия тупил в сирии, которые сами себя убивают ... текст свёрнут, показать
     
  • 3.28, БорБор (?), 22:56, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Если, вон, Байду использует

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

     
     
  • 4.32, funny.falcon (?), 06:39, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Яндекс использует. Прувы не дам, самому сорока на хвосте принесла. Но той сороке можно верить.
     
  • 4.75, Zver (??), 15:09, 14/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>Если, вон, Байду использует
    > Единственное мое знакомство с этой компанией произошло, когда с рабочего компа мамы
    > удалял их аналог мэйл.ру агента. Судя по тому, с каким скрипом
    > эта поделка удалялась, делаю вывод, что конторка-то не особо авторитетная. Сказали
    > бы, что Яндекс использует - тогда бы стоило обратить внимание.

    Яндекс по среавнению с Байду маленькая пупырка.

     
  • 2.19, Аноним (-), 21:01, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Согласен: нужно давно все переписать на JavaScript.
     
     
  • 3.25, Аноним (-), 21:26, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На Typescript!
     

  • 1.2, Crazy Alex (ok), 14:01, 11/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну, для дураков, наверное, встроенное шифрование - это хорошо, но вообще-то - комбайн. Это разные уровни и они должны реализовываться независимо. А здесь - прибили гвоздями к SSL...
     
     
  • 2.6, F (?), 14:46, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну, для дураков, наверное, встроенное шифрование - это хорошо, но вообще-то -
    > комбайн. Это разные уровни и они должны реализовываться независимо. А здесь
    > - прибили гвоздями к SSL...

    Оно во всех БД нынче есть. Не хочешь - не включай, но как фича нужно, чтобы для сравнения выглядеть хорошо на фоне остальных.

    Даром что MySQL с CockroachDB никак не сравнить в принципе. Но когда надо будет ноды запускать там, откуда даже ВПН тянуть не хочется, то может и пригодиться.

     
     
  • 3.8, Crazy Alex (ok), 16:02, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну разве что для сравнения... но это какой-то странный аргумент. Скорее поверю, что это сделано для "упрощения развёртывания" или чего-то подобного, т.е. в расчёте на не особо компетентного и не требовательного пользователя.

    А что за ноды такие, на которых может крутиться база, откуда VPN тянуть не хочется?

     
     
  • 4.12, пох (?), 17:03, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А что за ноды такие, на которых может крутиться база, откуда VPN тянуть не хочется?

    датацентр с суммарным out больше 10G, например (внутреннего, что характерно, байдового траффика. ничего такого особенного)
    то есть там есть "vpn", на самом деле, но если вам послышалось слово "шифрование" - вы плохо понимаете суть этой аббревиатуры.

    Гугль, конечно, для аналогичной цели поставил несколько шкафов, в каждом ДЦ, да, но это даже для гугля немножко недешево получилось.
    При том что большая часть этого траффика заведомо не нуждается в шифровании, это мусор, который в конечном итоге и так в интернет отдастся.

     
     
  • 5.14, Crazy Alex (ok), 17:42, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    э... ну и завернуть в шифрованный канал только то, что нужно защищать, нет? Не обязательно ж VPN держать только на уровне ДЦ-ДЦ, можно и более детально, тем более со всеми нынешними паппетами и прочими.

    Ну хоть убей - шифрование трафика - это не то, чем БД должна заниматься.

     
     
  • 6.15, Аноним (-), 18:08, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну хоть убей - шифрование трафика - это не то, чем БД
    > должна заниматься.

    Вы еще скажите, что QR-коды и вебсервак, собственный su, cron, calendar, netcat, dnscache -- это не то, что должна иметь любая серьезна система инициализации o_O

     
     
  • 7.16, Аноним (-), 19:09, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Серьезная как раз не должна.
     
     
  • 8.21, Аноним (-), 21:05, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А systemd шуточная получается Надо же ... текст свёрнут, показать
     
     
  • 9.26, Аноним (-), 21:28, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, но systemd точно от клоунов QR-код в систему инициализаци ахаха, рж... текст свёрнут, показать
     
  • 7.27, Crazy Alex (ok), 22:03, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А я это так и говорил. Причём всё это безумие отлично отражает безумие в самом коде. С нетерпением жду, когда эту хрень всерьёз копнут насчёт дыр - их там будет, не сейчас, так позже - код к поддержке не особо пригоден.
     
  • 6.35, Аноним (-), 07:29, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >шифрование трафика - это не то, чем БД должна заниматься

    Не учи -- не научатся. Все давно придумано: IPSec. А шифрование в БД сделано для тех, кто не умеет в шифрование и лишь слышал о нем (и если бд этого не умеет, значит, по _их_ мнению бд фуфло ^_^).

     
     
  • 7.46, пох (?), 12:17, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не учи -- не научатся. Все давно придумано: IPSec.

    ну вот покажите мне датацентр, работающий на ipsec - для начала.
    (а что, отличное ж место - нужен именно transport mode, который, в принципе, просто и легко встраивается в существующие структуры)

    для продолжения - подумайте, сколько ресурсов оно сожрет, когда на другом конце такой же датацентр, а не твой локалхост. В любом варианте - хоть в виде гуглешкафа на терминации, хоть в виде ручного строительства туннелей к серверам БД с каждой ноды, которой в теории может что-то там понадобиться - включая генерацию сертификатов (ну или раздачу и своевременную замену кучи psk) и отслеживание, чтобы вся эта мега-архитектура внезапно не развалилась (или не поломали то, с чего как раз и раздается).
    А в базе байды, тупо, помимо прочего, данные юзеров, которые в общем-то нехорошо светить всему миру.

    Ну и еще - шифрование в БД позволяет не изобретать свой велосипед с аутентификацией (в mysql ее пару раз, помнится, ломали), и не гонять пароли открытым текстом//тупо доверять хосту по айпишнику, если что-то не изобрелось. Пейсатели таз банных редко бывают хорошими криптографами, увы. А вот прикрутить готовую ssl - если не заморачиваться сложными ходами - может каждый студент. И оно таки будет лучше защищено, чем вышеописанная студенческая поделка, и работать надежнее, чем еще выше описанный ипсековый спагетти-монстр.

    Ну а если в базе у вас access_log ненужно-хоста - то никто и не заставляет использовать шифрование вовсе.

     
     
  • 8.58, Аноним (-), 21:26, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Чей ДЦ Гугла Вы про что Гугл может и строит свои ДЦ Крупный провайдеры строя... большой текст свёрнут, показать
     
     
  • 9.59, Аноним (-), 21:34, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    s 1000 до 50000 тыс запросов 1000 до 50000 запросов Да, всего 50 тыс запросов... текст свёрнут, показать
     
  • 9.78, пох (?), 00:11, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    дорогой админ локалхоста, вынужден сообщить тебе страшное датацентры бывают не ... большой текст свёрнут, показать
     
     
  • 10.85, Аноним (-), 21:34, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ты бы почитал про MPLS Тебе чтоли все разжевывать надо Если что, то я имел вви... текст свёрнут, показать
     
     
  • 11.86, пох (?), 16:08, 17/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    спасибо, поржал ... текст свёрнут, показать
     
  • 5.22, qsdg (ok), 21:21, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Раньше гугля и не обязывал внутренний свой трафик между серверами шифровать.
    Пока NSA не спалилось, что оно прослушивало их внутренний трафик на международных каналах. С тех пор в срочном порядке всех обязали включить флаг шифрования для внутренних RPC.
     
     
  • 6.37, Аноним (-), 07:36, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >прослушивало их внутренний трафик

    И что, что прослушивали? У них там пароли в открытом виде чтоли передавались? Или письма ген. дира? Ну, тогда это проблема не БД, а безопасников, которые все проморгали.

     
     
  • 7.40, qsdg (ok), 08:32, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > И что, что прослушивали? У них там пароли в открытом виде чтоли
    > передавались? Или письма ген. дира? Ну, тогда это проблема не БД,
    > а безопасников, которые все проморгали.

    Вы не поняли. "Внутренний трафик гугла" это, например, репликация БД всяких сервисов типа GMail между датацентрами. А по GMail многие ген. диры передают свои пароли.

    Гуглите по "snowden leaks".

     
  • 6.47, пох (?), 12:20, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Раньше гугля и не обязывал внутренний свой трафик между серверами шифровать.

    они сейчас шифруют _собственную_ n*10G опту между площадками - без всяких "международных каналов". На случай, если все же кто-то поставил в колодце непредусмотренный сплиттер.

    Поскольку если NSA сумеет обойтись без их помощи с дешифровкой - кредитов под 0% не дадут.


     
     
  • 7.53, Вареник (?), 16:36, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Поскольку если NSA сумеет обойтись без их помощи с дешифровкой - кредитов
    > под 0% не дадут.

    Вот именно. Пусть NSA покупают украденную у пользователей всего мира инфу, а не тупо тырят )))

     

  • 1.7, xm (ok), 15:41, 11/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Название, конечно, доставляет. Такое, buggy :-D
     
     
  • 2.17, Anonim (??), 19:48, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Тараканы и жуки в не очень родственных отношениях
     
     
  • 3.23, qsdg (ok), 21:22, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Тараканы и жуки в не очень родственных отношениях

    Да и в холодных странах с тараканами легко справлялись -- уходили зимой ночевать к соседям. Тараканы все замерзали, бедненькие :(

     

  • 1.10, Аноним (-), 16:43, 11/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Каждый считает своим долгом в первый стабильный релиз добавить слова "отказоустойчивый" и "защищенный".
     
     
  • 2.20, Аноним (-), 21:04, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почему каждый? Это неправда.
     
  • 2.24, qsdg (ok), 21:24, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Каждый считает своим долгом в первый стабильный релиз добавить слова "отказоустойчивый"
    > и "защищенный".

    Но, к их чести, они сперва проконсультировались с Aphyr почти год назад https://jepsen.io/analyses/cockroachdb-beta-20160829

    Если вы не в курсе, кто это такой, то почитайте его остальные ревью NoSQL баз по тегу jepsen. На его тестах почти все новомодные базы failed miserably при network partitioning.

     
  • 2.49, пох (?), 12:55, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Каждый считает своим долгом в первый стабильный релиз добавить слова "отказоустойчивый"
    > и "защищенный".

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

    Чинить в их масштабах развалившуюся репликацию какого-нибудь mysql лучше всего напалмом.

     

  • 1.55, anonymous (??), 17:53, 12/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    люди подскажите чем вы пользуетесь для хранения пусть просто key-value, но гарантированного хранения с записью на диск (возможно с одновременной синхронной записью на slave, хотя по идее можно просто хранить на raid) и масштабированием (подключением/отключением/ребалансировкой серверов без brain split как у всяких cassandra/riak).

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

     
     
  • 2.76, нах (?), 15:30, 14/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    осспадя - да nosql-ей - мильен с тыщами, не монгой единой.
    кто что осилил, тем и пользуется, и не факт что это что-то надо тебе. (отдельный вопрос, а как ты чисто теоретически себе представляешь масштабирование _записи_. Не то чтоб было совсем никак, но есть, хм, сомнения в понимании явления.)

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

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

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


     
     
  • 4.79, пох (?), 00:33, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Да вот как раз позиционируется как strongly-consistent ACID.

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

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

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

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

     
     
  • 5.80, Zver (??), 04:35, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Да вот как раз позиционируется как strongly-consistent ACID.
    > я нарочно подчеркнул - надежность _хранения_. То есть она strongly от разваливания,

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

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

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

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

     
     
  • 6.81, лютый жабист__ (?), 07:49, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В Монге с консистентностью нормально только внутри документа.

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

     
     
  • 7.82, пох (?), 09:06, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> В Монге с консистентностью нормально только внутри документа.
    > При этом надо учитывать, что "документ" в Монге это аналог слепленных в
    > РДБМС join-ом n таблиц.

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

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

     
  • 3.83, anonymous (??), 10:05, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >как ты чисто теоретически себе представляешь масштабирование _записи_

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

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

     
     
  • 4.84, пох (?), 12:14, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > мне сейчас нужно создать масштабируемую систему и либо я сейчас буду опять с нуля писать
    > мегахитрые костыли поверх SQL либо возьму что-то уже готовое.

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

     

  • 1.73, Zver (??), 15:01, 14/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Прощай Монга и MySQL?
    Как оно вообще? Кто-нибудь тестировал, использовал? Действительно ли так хороша, как описывают?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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