https://www.opennet.me/openforum/vsluhforumID3/111215.html Состоялся (https://www.cockroachlabs.com/blog/cockroachdb-1-0-release/) первый стабильный выпуск распределённой СУБД CockroachDB (https://www.cockroachlabs.com/), позволяющей создавать высоконадёжные горизонтально масштабируемые хранилища. При помощи CockroachDB можно развернуть географически распределённые системы, отличающиеся высокой живучестью и не зависящие от сбоев дисков, узлов и даже выхода из строя целых центров обработки данных. Ситуации сбоев обрабатываются автоматически и работа восстанавливается с минимальными задержками. При этом CockroachDB гарантирует целостность ACID-транзакций, предоставляет возможность использования SQL для манипуляции с данными, позволяет вносить изменения в схему хранения на лету, поддерживает индексы и внешние ключи.<br><br><br><br>CockroachDB разработан под впечатлением от технологий Google Spanner (http://research.google.com/archive/spanner.html) и F1 (http://research.google.com/pubs/pub38125.html), но в отличие от них является полностью открытым продуктом. Код проекта напис https://www.opennet.me/openforum/vsluhforumID3/111215.html#86 Wed, 17 May 2017 13:08:25 GMT &gt; Ты бы почитал про MPLS.<br><br>спасибо, поржал.<br><br><br> https://www.opennet.me/openforum/vsluhforumID3/111215.html#85 Mon, 15 May 2017 18:34:01 GMT &gt;А теперь расскажи, чего ж это гугль-то не обходится, и запихнул свои mpls'ы внуть шифрованного канала, ась? Вот тупые, да?<br><br>Ты бы почитал про MPLS. Тебе чтоли все разжевывать надо? Если что, то я имел ввиду MPLS/VPN. Да, там уже само по себе встроен шифрованный канал. Нужен ли в таком случае IPSec дело десятое, т.к. _мало_ кто сможет приобрести _свой_ канал от точки А до точки Б.<br><br>Что касается гугла, то они могут воротить такие вещи, которые тебе и не снились. И у них нет вообще вопроса о том, сколько и что жрет. Вообще-то есть, ибо стоимость электро-энергии у них в первой тройке затрат. Ну, куда уж тебе или мне думать о таких "мелочах". Электричество ж дешевое. Когда у тебя максимум 1000 железок.<br> https://www.opennet.me/openforum/vsluhforumID3/111215.html#84 Mon, 15 May 2017 09:14:37 GMT &gt; мне сейчас нужно создать масштабируемую систему и либо я сейчас буду опять с нуля писать<br>&gt; мегахитрые костыли поверх SQL либо возьму что-то уже готовое.<br><br>при таком раскладе я бы скачал китайский код, и начал его читать - не в плане как они это сделали, а в плане - я смогу это _сам_ без помощи китайцев поддерживать и менять в нужную мне сторону, или оно так написано что ну его нафиг.<br>Потому что поддерживать и менять в такой постановке задачи все равно придется. А тут за тебя, зато, китаец цельный облачный sql написал.<br><br> https://www.opennet.me/openforum/vsluhforumID3/111215.html#83 Mon, 15 May 2017 07:05:04 GMT &gt;как ты чисто теоретически себе представляешь масштабирование _записи_<br><br>я делал такие костыли поверх SQL и даже свою сетевую файловую систему писал, но хочу знать как это делают другие и что используют. как делал я: берем хеш от ключа (это дает нам нормальное распределение) далее берем его младшие биты и используя младшие биты в качестве индекса в массиве понимаем на каком сервере хранится ключ. это простой вариант, в сложном мы по битам понимаем в каком чанке хранится ключ, а далее узнаем на каком сервере хранится чанк. это именно масштабирование записи и до кучи и чтения. но приходится изобретать свою сложную обвязку на чтение и на запись если нужно перемещение ключей (решардирование) online.<br><br>мне сейчас нужно создать масштабируемую систему и либо я сейчас буду опять с нуля писать мегахитрые костыли поверх SQL либо возьму что-то уже готовое. нужно хотябы хранилище ключ-значение которое бы всегда сохраняла ключ на диск прежде чем сказать что оно его записало, чтобы сервера туда легко добавлялись и удаляли https://www.opennet.me/openforum/vsluhforumID3/111215.html#82 Mon, 15 May 2017 06:06:08 GMT &gt;&gt; В Монге с консистентностью нормально только внутри документа.<br>&gt; При этом надо учитывать, что "документ" в Монге это аналог слепленных в <br>&gt; РДБМС join-ом n таблиц.<br><br>скорее аналог ненормализованной таблицы. Если бы этим все и ограничивалось, монга была бы ненужна. Храни точно такую же в sql, кто не дает. Я когда-то и пострашнее видел - (oid integer, data blob). Иффсе. Вся база. sql не возражал. На жабке было, кстати, написано, хехехе. Ентерпрайсной.<br><br>С консистентностью там "все нормально" в том смысле, что оно либо теряет свой "документ" целиком, либо в хранилке он тоже целиком. Для остального в новой-модной хранилке у нее тоже есть костылик, но я вот не особенно уверен, что если ты работаешь с чем-то, чего терять никак нельзя, стоит использовать монгу с костыликами.<br><br> https://www.opennet.me/openforum/vsluhforumID3/111215.html#81 Mon, 15 May 2017 04:49:25 GMT &gt; В Монге с консистентностью нормально только внутри документа.<br><br>При этом надо учитывать, что "документ" в Монге это аналог слепленных в РДБМС join-ом n таблиц. Итого консистентность есть и отличная, плюс клёвые фишки в духе fineOneAndDelete и подобное. <br> https://www.opennet.me/openforum/vsluhforumID3/111215.html#80 Mon, 15 May 2017 01:35:46 GMT &gt;&gt; Да вот как раз позиционируется как strongly-consistent ACID.<br>&gt; я нарочно подчеркнул - надежность _хранения_. То есть она strongly от разваливания, <br><br>Соответствие ACID подразумевает сохранность данных после завершения транзакции. А не защиту от разваливания. <br><br>&gt; ну здрасьте, кто начал с key-value? <br><br>Я вообще ничего не говорил про key-value.<br><br>В Монге с консистентностью нормально только внутри документа. <br><br> https://www.opennet.me/openforum/vsluhforumID3/111215.html#79 Sun, 14 May 2017 21:33:59 GMT &gt; Да вот как раз позиционируется как strongly-consistent ACID.<br><br>я нарочно подчеркнул - надежность _хранения_. То есть она strongly от разваливания, а не от потери данных нафиг - если я правильно угадываю, для чего байде такая хреновина, они могут себе позволить иногда что-то потерять, это не деньги.<br>А раз у тебя сразу речь про локальные рейды - значит, это не тот случай.<br><br>(впрочем, с mysql'ем тоже теряется, не смотря на все системы подпорочек и костыликов)<br><br>&gt; И я не про НоСКУЛ<br><br>ну здрасьте, кто начал с key-value? Это как раз типичная nosql задача (хотя и есть мнения экспертов, что оно всегда вылазит потом боком). Но вот с надежностью _хранения_ у nosql'ей обычно беда-беда.<br>(монга песня отдельная, но это и не голая key-value, они себя считают document database, и там в общем все нормально с консистентностью и транзакциями, главное в один непрекрасный день не понять, что ты в их модель данных внезапно не укладываешься и нужно что-то, что умеет join ;)<br><br> https://www.opennet.me/openforum/vsluhforumID3/111215.html#78 Sun, 14 May 2017 21:11:54 GMT &gt;&gt;ну вот покажите мне датацентр, работающий на ipsec - для начала.<br>&gt; Чей ДЦ? Гугла? Вы про что?<br><br>дорогой админ локалхоста, вынужден сообщить тебе страшное: датацентры бывают не только у гугля, и их необязательно строить самому, можно арендовать кусочек чужого, как почти все и делают. Что, как ни странно, вовсе не привело пока к практике внутри арендованных рядов стоек полностью переходить на ipsec. Хотя, в целом, это как раз вполне реализуемо (правда, можно поймать феерический п-ц, если оно вдруг развалится тоже глобально), когда и инфраструктура под твоим контролем вся, и железки все в одной куче.<br><br>А вот арендовать кусочек чужой шифровалки канала между датацентрами - это довольно дорого, ненадежно, и неудобно. Поэтому в большинстве случаев траффик гуляет совершенно нешифрованным, в предположении что залетный горе-хакер ниасилит выделить в терабайтах мусора хоть что-то ценное, а местным инженерам не до того. Но что-то ценное неплохо бы прикрыть end2end, оно так обычно проще, чем глобальные решения (когда