The OpenNET Project / Index page

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

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от opennews (ok) on 11-Май-17, 12:58 
Состоялся (https://www.cockroachlabs.com/blog/cockroachdb-1-0-release/)  первый стабильный выпуск распределённой СУБД CockroachDB (https://www.cockroachlabs.com/), позволяющей создавать высоконадёжные горизонтально масштабируемые хранилища. При помощи CockroachDB можно развернуть географически распределённые системы, отличающиеся высокой живучестью и не зависящие от сбоев дисков, узлов и даже выхода из строя целых центров обработки данных. Ситуации сбоев обрабатываются автоматически и работа восстанавливается с минимальными задержками. При этом CockroachDB гарантирует целостность ACID-транзакций, предоставляет возможность использования SQL для  манипуляции с данными, позволяет вносить изменения в схему хранения на лету, поддерживает индексы и внешние ключи.

CockroachDB разработан под впечатлением от технологий  Google Spanner (http://research.google.com/archive/spanner.html) и F1 (http://research.google.com/pubs/pub38125.html), но в отличие от них является полностью открытым продуктом. Код проекта написан на языке Go и распространяется (https://github.com/cockroachdb/cockroach/) под лицензией Apache 2.0. Из наиболее подходящих для  CockroachDB применений отмечается организация хранения данных приложений, от которых требуется постоянная доступность и целостность данных, а также гибкая масштабируемость (расширение сводится к добавлению (https://www.cockroachlabs.com/docs/start-a-node.html) новых узлов, которые автоматически включаются в кластер).


CockroachDB предоставляет средства для автоматической репликации, ребалансировки хранилища, обнаружения сбоев и восстановления, при минимальной настройке и обслуживании, что отлично подходит для создания распределённых хранилищ и облачных решений, развёртываемых поверх нескольких центров обработки данных. Система обработки транзакций соответствует требованиям ACID (https://en.wikipedia.org/wiki/ACID). Обмен данными между узлами производится с использованием шифрования. Аутентификация выполняется на основе SSL-сертификатов. Для клиентов предусмотрена система разделения привилегий (https://www.cockroachlabs.com/docs/privileges.html). Для приложений предоставляется высокоуровневый SQL API (https://www.cockroachlabs.com/docs/learn-cockroachdb-sql.html) (урезанное подмножество SQL (https://www.cockroachlabs.com/docs/sql-grammar.html)), совместимый (https://www.cockroachlabs.com/docs/install-client-drivers.html) с клиентскими драйверами для PostgreSQL.

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

На низком уровне данные хранятся (https://github.com/cockroachdb/cockroach/blob/master/docs/de...) в формате  RocksDB (https://www.opennet.ru/opennews/art.shtml?num=38499) (вариант LevelDB (https://www.opennet.ru/opennews/art.shtml?num=31325)) в виде связок ключ/значение с разбивкой на сегменты, охватывающие определённый диапазон данных (по умолчанию размер сегмента - 64MB). После заполнения сегмента данные разбиваются на два новых сегмента, каждый из которых охватывает более узкий диапазон значений, и этот процесс разбиения производится непрерывно. При наличии нескольких узлов образуемые новые сегменты автоматически распределяются на узлы, на которых больше свободных ресурсов. Ребалансировка производится с использованием P2P-протокола gossip (https://en.wikipedia.org/wiki/Gossip_protocol), который помогает поддерживать информацию о доступных адресах узлов и состоянии их ресурсов.


Для обеспечения отказоустойчивости данные реплицируются на несколько узлов, на основе которых строится кластер без единой точки отказа, способный работать в режиме multi-active. Для обеспечения непротиворечивости реплик при записи используется метод достижения консенсуса на основе алгоритма Raft (https://raft.github.io/). Для обеспечения непротиворечивости операций чтения используется собственный алгоритм (https://www.cockroachlabs.com/docs/strong-consistency.html) синхронизации на основе временных меток. В рамках одной транзакции могут охватываться данные с разных узлов. При репликации данных учитывается топология кластера - дубликаты создаются с учётом обеспечения резервирования разных серверов, стоек и ЦОД.


URL: https://www.cockroachlabs.com/blog/cockroachdb-1-0-release/

Новость: http://www.opennet.ru/opennews/art.shtml?num=46529

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

Оглавление

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


1. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –14 +/
Сообщение от cmp (ok) on 11-Май-17, 12:58 
> написан на языке Go

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

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

3. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +2 +/
Сообщение от Crazy Alex (ok) on 11-Май-17, 14:03 
Да хрен его знает... Если, вон, Байду использует - значит, оно хоть как-то живое и, в общем, вполне заслуживает упоминания.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –14 +/
Сообщение от cmp (ok) on 11-Май-17, 14:38 
Да надо отдельный стрим делать новостей от британских ученых и разрабов на го, я уже настроился почитать, а тут на 2ом обзаце поддых, явы мало блин, надо еще одну тормозную хрень.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +3 +/
Сообщение от F on 11-Май-17, 14:44 
Во-первых, надо уметь готовить. Во-вторых, в промышленном использовании Java и Go очень даже ничего смотрятся. А, в-третьих, стоимость сопровождения тоже есть величина интересная.

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

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

9. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Crazy Alex (ok) on 11-Май-17, 16:03 
а что там в Go с тормозами?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

13. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от _ (??) on 11-Май-17, 17:09 
Не хуже чем у других! (С)   :-)
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +1 +/
Сообщение от _ (??) on 11-Май-17, 17:03 
Как страшно жить! (С)
Мучайся, Go взлетел и его вокруг будет только больше и больше.
(демоническим голосом) Му-ха-ха-хаа! 8-)
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

30. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от cmp (ok) on 12-Май-17, 01:12 
Ага, как и ява, 10 ? 15 ? лет обещают, что она будет сравнима по скорости с СИ и жрать меньше памяти, и где ?

Что на го используется и не имеет вменяемых аналогов? просто очередной язык из десятков, отличается лишь наличием плодовитых адептов, вот не лень же людям, но явашников всяко больше, и пхпшников больше, а разница в производительности ничтожна, значит ява и пхп завтра точно никуда не денутся, а го хз, завтра бабки в него вливать перестанут, все адепты разбегутся и 2 калеки сообщества останется, ну или не перестанут бабло лить, будет 50 оплачиваемых калек, напишут ГоОС, ГоСУБД потом поймут, что медленно, что надо интегрировать модули с функциями на нативных процессорных инструкциях, потом поймут, что проще выкинуть прослойку самого Го, либо сделать его жирным как пхп, либо оставить медленным.

Сколько еще раз надо это пройти, чтобы дошло ? Ну, в добрый путь, я тут подожду, все равно вернетесь.

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

33. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от лютый жабист__ on 12-Май-17, 06:43 
>Ага, как и ява, 10 ? 15 ? лет обещают, что она будет сравнима по скорости с СИ и жрать меньше памяти, и где ?

Про "жрать меньше памяти" - норкоманов не слушай. В жабе не ломают совместимость соответственно, ничего не поменяется. И для лулзов инфа: например на хранение одного Integer жаба тратит порядка 45 байт в 32битном режиме и 75 байт в 64битном. Ужасайся 8)))

Просто негомнокодеры знают когда надо int использовать, а когда Integer и всё хорошо 8)))

"по скорости с СИ" это уже давно так. Надо понимать, что трата ОЗУ и скорость работы обычно (не всегда, разумеется) обратно пропорциональны. Например Array меньше жрёт, чем HashMap, а ConcurrentHashMap ещё быстрее. Я в своём кругу видел много сишного софта на array-ях, которое мало ело ОЗУ и было НИКАКОЕ по скорости, по сравнению с могучей жабкой на адекватных стурктурах.

Пятничные Мантры:
1. ОЗУ нынче дешевое.
2. Жаба не тормозит.

8))))

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

34. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +3 +/
Сообщение от Аноним (??) on 12-Май-17, 07:25 
>Я в своём кругу видел много сишного софта на array-ях, которое мало ело ОЗУ и было НИКАКОЕ по скорости, по сравнению с могучей жабкой на адекватных стурктурах.
>в своём кругу

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

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

36. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от лютый жабист__ on 12-Май-17, 07:36 
>Найдите нормально сишнека и не позорьтесь со своими выводами

Нормальный сишник это такая сущность, которая обитает в Астрале, которая может, но не хочет написать Cassandra, Lucene, Spark [список из 100500 крутых прог не влез]... 8)))
Все его ищут, но никто не находит....

Ты про анси си же, а не тормозные плюсы? :) Кстати, плюсы умеют так:

Set<String> colleagues = employees.stream().filter(e -> !e.getFullname().equals(emp.getFullname())).filter(e -> e.getActiveDepts().stream().anyMatch(emp.getActiveDepts()::contains)).map(e -> e.getFullname()).collect(Collectors.toSet());

это аналог SQL-запроса с join-ом пары таблиц. Но всё на банальном жабомассиве, соответственно скорость лютая, что никакой SQL рядом не лежал. 8)

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

38. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 12-Май-17, 07:45 
>Нормальный сишник это такая сущность, которая обитает в Астрале

Ваш ограниченное окружение вкупе с "правильно мнение -- только мое мнение" заведет этот спор в тупик.

>Но всё на банальном жабомассиве, соответственно скорость лютая

Вам уже поясняли, что си быстрее явы из-за отсутствия оверхеда. Вы этого так и не поняли. А тормозное ПО можно писать хоть на ассемблере и что, ассемблер тормознее явы? Такой ваш вывод? Это риторический вопрос.

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

39. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от лютый жабист__ on 12-Май-17, 08:18 
> Вам уже поясняли, что си быстрее явы из-за отсутствия оверхеда.

IBMовские mainframe-ы исполняют сразу жабу. У тебя нету мэйнфрэйма? Наверное и на десктопе меньше 32ГБ ОЗУ? 8)

На самом деле и с x86* всё не так радужно, как тебе мерещится: на си компилишь с оптимизацией  и часто получаешь глюкодром. Только давай только не про твою кульпрожку на 50КБ или про некие фофаны навроде генту, которое умельцы компилят с -03 8))) В среднем уровень "обычного кодера-сишнека на ЗП чуть выше прожиточного минимума" сильно ниже тех сишников, которые JVM пишут. В итоге упс... вся бигдата написана на тормозной жабе.

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

41. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 12-Май-17, 10:34 
Если джава такая замечательная, то почему она написана на тормозном C++? Совпадениенедумаю.
Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

45. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от cmp (ok) on 12-Май-17, 12:16 
Ява быстрее си, ахахаха, тебя псаки покусала или ты с рождения такой?
Ответить | Правка | Наверх | Cообщить модератору

50. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +3 +/
Сообщение от Аноним (??) on 12-Май-17, 13:30 
Я думаю что он пишет на Си так что у него всегда Java быстрее работает. А понять что детали реализации и методы испльзования не отражают проблем языка - это слишком сложно для него. Поверьте мне, смысла разговаривать с ним нет - он либо глуп, либо просто троллит. Так или иначе, цель его не разобраться в обстоятельствах и найти истину, а утвердить свою позицию вне зависимости от ее (позиции) адекватности, правдивости и вменяемости.
Он слабый оппонент, очень слабый. Не тратьте на него свое время зря, он того не стоит.
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

56. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от лютый жабист__ on 12-Май-17, 20:04 
> Я думаю что он пишет на Си так что у него всегда
> Java быстрее работает. А понять что детали реализации и методы испльзования

Пока ты будешь на своём анси си реализовывать хэшмэп, я 50 раз закончу всю прогу на жабе. Возьмёшь тормозные плюсы с хэшмэпом, выхлоп от си сразу уменьшится до почти нуля. Да и в плюсах нет ничего близкого к функционалу бесплатного аппсервера, например wildfly. Кластеризация из коробки, транзакционный код с офигенной интеграцией с ORM в RDBMS, брокер сообщений, мелкие плюшки в виде cluster-wide singleton и тд и тп

Кстати, аппсерверы JavaEE пишутся не на си, а на жабе. Шах и мат :))))

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

60. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +4 +/
Сообщение от Аноним (??) on 12-Май-17, 21:42 
>Пока ты будешь на своём анси си реализовывать хэшмэп, я 50 раз закончу всю прогу на жабе.

Как там говорится, слив защитан. Причем тут скорость разработки и скорость ЯП? Не причем, это просто ява головного мозга. И тебе и мне лично пофиг кто или что там быстрее. Ты сюда не за этим пришел, это очевидно. Желаю дальше "пиарить" себя и яву. Есть куда совершенствоваться :)

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

61. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +1 +/
Сообщение от Аноним (??) on 12-Май-17, 21:55 
> Пока ты будешь на своём анси си реализовывать хэшмэп, я 50 раз закончу всю прогу на жабе.

Ты действительно думаешь что это честное сравнение? Ты либо глуn, либо ...
Берешь готовую реализацию hashmap на java и сравниваешь с отсутствием реализации. А давай я сделаю так: https://developer.gnome.org/glib/2.52/glib-Hash-Tables.html

> Возьмёшь тормозные плюсы с хэшмэпом, выхлоп от си сразу уменьшится до почти нуля.

беру glib, дальше че?

> Да и в плюсах нет ничего близкого к функционалу бесплатного аппсервера, например wildfly. Кластеризация из коробки, транзакционный код с офигенной интеграцией с ORM в RDBMS, брокер сообщений, мелкие плюшки в виде cluster-wide singleton и тд и тп

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

> Кстати, аппсерверы JavaEE пишутся не на си, а на жабе. Шах и мат :))))

И шахматист из тебя лоxоватый: Lisp-код пишется на Lisp, а не на java. Внезапно Java теперь отcтой.

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

67. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от лютый жабист__ on 13-Май-17, 08:22 
> Берешь готовую реализацию hashmap на java и сравниваешь с отсутствием реализации.

Это моя проблема, что в core java есть много плюшек, которых у вас нет? Назвался груздем...
Непонятно с какого перепуга ты чё-то там берёшь готовое, а то я скажу сейчас что я беру кассандру готовую, а у тебя где субд такого уровня?

> беру glib, дальше че?

Ты забыл чтоли, у нас прога под винду? Компилер vs2012. Какой такой глиб? 8))))  

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

72. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +1 +/
Сообщение от Аноним (??) on 14-Май-17, 13:01 
>а то я скажу сейчас что я беру кассандру готовую, а у тебя где субд такого уровня?

Ты всегда берешь кассандру без постановки задачи? :) И как связано взятие чего-то готово с тем, что надо самому писать. Ты вот эту кассандру вдоль и поперек перелопачиваешь под каждую задачу, знаешь от и до ее внутренности? Или ты просто всегда берешь продукт на яве и пофиг, что он не вписывается в задачу.

Я скажу, что могу взять sqlite, pgsql, Oracle DB, MongoDB, туже кассандру и т.д., т.к. это вообще не относится к моему коду. Человек привел корректный пример с glib, а ты перекинул разговор в свою кассандру, будто ты ее встроишь в свой код, как неотъемлемую часть.

>Ты забыл чтоли, у нас прога под винду? Компилер vs2012. Какой такой глиб? 8))))

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

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

65. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от cmp (ok) on 13-Май-17, 07:13 
> Пока ты будешь на своём анси си реализовывать хэшмэп

Да есть готовые, полно, но на 10к элементов они показывают худшие результаты по сравнению с тупым перебором.

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

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

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

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

68. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –2 +/
Сообщение от лютый жабист__ on 13-Май-17, 08:24 
> Да есть готовые, полно, но на 10к элементов они показывают худшие результаты
> по сравнению с тупым перебором.

8)))))) прохладны твои былины, бро.

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

57. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Адепт Анонима on 12-Май-17, 20:44 
Никто не спорит, что при грамотной писанине на Си программа будет быстрее и памяти в разы скорее всего потребуется меньше.

Не в этом дело. Жаба создавалась не для этого.
Вы рассуждаете как технарь, со своей технарьской низкоуровневой колокольни.

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

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

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

Так или иначе, Sun Microsystems наверно быстрее остальных прочухали этот тренд и выкатили свою жабу. Не они, так кто-нить другой выкатил что-нибудь подобное. Первое время жаба была очень далека от идеала, но как показало время -удалось состряпать приличный иструмент для широкого серьезного применения, не распугав при этом технарей и бизнес.

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

Из этого я не вывожу, что Жаба, как платформа, это бест оф де бест.
Но ее, как правило, всегда рассмаривают в качестве претендента для больших проектов.

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

62. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 12-Май-17, 22:00 
Да, все вроде бы верно, но время Java проходит. По инерции еще будет держаться вся эта инфраструктура, но она будет замещена. Помню когла начинал с Java, она действительно выглядела локомативом, но это прошло.

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

Раньше не было, но сегодня существуют технологии которые обходят и теперь всегда будут обходить Java. Зациклитесь на java - уйдете в прошло. Это вопрос времени.

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

63. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Адепт Анонима on 13-Май-17, 00:12 
>> которые обходят и теперь всегда будут обходить Java

Выйграть битву не значит выйграть войну.

Построение больших систем требует комплексного подхода.
На поле энтерпрайза, для чего она вообще создавалась, реально никого и близко не видно.
Местами можно вкрячить что-то другое и такое бывает оправдано, но общую температуру по больнице это не меняет.
Жаба это уже монструозная "экосистема".
Плюс Андройд значительно только укрепил ее. Врятли Жабу оттуда выкидывать будут.

Также появились решения на база JVM такие как Scala, Kotlin, Closure и т.д. со своей идеологией и подходами в разработке, но они тоже в этом же лагере.
Ну и сама Жаба не стоит на месте и преображается, много чего добавляют нового.
Стагнации пока не наблюдается. Также ее сделали Опенсоурс, что тоже плюс.

Думаю, что игроки уже давно распределились и по сути позиции не меняются.
Сейчас это С/С++, Python, NodeJS, Java, C#, PHP + вебня и немного Erlang с Ruby.

Вот сейчас многие уповают на Rust, но он, как я понимаю, идет на замену С/С++.
Говорить о каких-то прорывах пока не приходится.

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

66. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 13-Май-17, 08:12 
Прочел вас и вспомнил AT&T которая считала рынок и свое положение непоколебимым. Мне честно не хочется тратить время и доказывать что ваши доводы устарели или они теряют силу здесь и сейчас. Положение вещей не изменится от того что вы думаете что java - это навсегда и надолго. Время пройдет как пройдет java.
Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

71. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Адепт Анонима on 13-Май-17, 23:52 
Хотя вы не указали что-то конкретное, я уважаю ваше мнение и думаю, что оно вполне имеет основание.
Появиться решение лучше - перейдем на него. Делов-то.

Сам посматриванию на D, Ocaml и даже на Red(http://www.red-lang.org/).
Выглядят весьма интересно и мощно, но объективно нужно немало потратить времени на освоение.
А времени, к сожалению, пока свободного нет.

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

69. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от Ydro on 13-Май-17, 13:47 
У меня программирование - домашнее хобби, в итоге: Сто раз читал книги по Jave - да, всё красиво и понятно, но какого чёрта нет беззнаковых переменных - это же бредятина полная.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

70. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от Led (ok) on 13-Май-17, 22:47 
> У меня программирование - домашнее хобби

"Сбегай за пивом!" и "Подавай ужин!" - это не программирование.

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

51. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от Вареник on 12-Май-17, 16:29 
>> Найдите нормально сишнека и не позорьтесь со своими выводами. Хотя нет, позорьтесь, ява головного мозга не лечится.

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

То же самое с рустами... Ура, наш массив на HelloWorld не тормозит! Наше копирование из sdtin в stdout летает!

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

43. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от диванный аналитик on 12-Май-17, 11:08 
В реальном мире программные продукты пишут ради денег. Java позволяет получить достаточно хороший результат в соотношении цена/удобство/скорость разработки/скорость работы. При этом она достаточно безболезненно запускается на разных платформах. В реальном мире всех волнуют лишь деньги, добро пожаловать
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

48. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от cmp (ok) on 12-Май-17, 12:34 
> В реальном мире программные продукты пишут ради денег

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

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

52. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от Вареник on 12-Май-17, 16:32 
>> В реальном мире программные продукты пишут ради денег
> А еще воруют, убивают и насилуют в реальном мире, причем кое-где тоже
> за деньги.

Поэтому насильники-профессионалы предпочитают средненький но практичный Глок эпичным ДезертИглам. Потому что реальный мир.

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

54. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от cmp (ok) on 12-Май-17, 17:44 
профессионалы? это кто например? армия тупил в сирии, которые сами себя убивают довольно не плохо, или их оппоненты из сирийской армии, которым, что выдали, или любой другой армии, или  самой "крутой" армии юса, которые при менее чем 10ти кратном превосходстве клянчат эвакуацию.

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

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

28. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –3 +/
Сообщение от БорБор on 11-Май-17, 22:56 
>Если, вон, Байду использует

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

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

32. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от funny.falcon on 12-Май-17, 06:39 
Яндекс использует. Прувы не дам, самому сорока на хвосте принесла. Но той сороке можно верить.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

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

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

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

19. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +2 +/
Сообщение от Аноним (??) on 11-Май-17, 21:01 
Согласен: нужно давно все переписать на JavaScript.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

25. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от Аноним (??) on 11-Май-17, 21:26 
На Typescript!
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

2. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +1 +/
Сообщение от Crazy Alex (ok) on 11-Май-17, 14:01 
Ну, для дураков, наверное, встроенное шифрование - это хорошо, но вообще-то - комбайн. Это разные уровни и они должны реализовываться независимо. А здесь - прибили гвоздями к SSL...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от F on 11-Май-17, 14:46 
> Ну, для дураков, наверное, встроенное шифрование - это хорошо, но вообще-то -
> комбайн. Это разные уровни и они должны реализовываться независимо. А здесь
> - прибили гвоздями к SSL...

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

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

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

8. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от Crazy Alex (ok) on 11-Май-17, 16:02 
Ну разве что для сравнения... но это какой-то странный аргумент. Скорее поверю, что это сделано для "упрощения развёртывания" или чего-то подобного, т.е. в расчёте на не особо компетентного и не требовательного пользователя.

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

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

12. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от пох on 11-Май-17, 17:03 
> А что за ноды такие, на которых может крутиться база, откуда VPN тянуть не хочется?

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

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

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

14. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Crazy Alex (ok) on 11-Май-17, 17:42 
э... ну и завернуть в шифрованный канал только то, что нужно защищать, нет? Не обязательно ж VPN держать только на уровне ДЦ-ДЦ, можно и более детально, тем более со всеми нынешними паппетами и прочими.

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

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

15. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 11-Май-17, 18:08 
> Ну хоть убей - шифрование трафика - это не то, чем БД
> должна заниматься.

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

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

16. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +1 +/
Сообщение от Аноним (??) on 11-Май-17, 19:09 
Серьезная как раз не должна.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

21. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 11-Май-17, 21:05 
А systemd шуточная получается? Надо же.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

26. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 11-Май-17, 21:28 
Не знаю, но systemd точно от клоунов. QR-код в систему инициализаци))) ахаха, ржунимагу
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

27. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Crazy Alex (ok) on 11-Май-17, 22:03 
А я это так и говорил. Причём всё это безумие отлично отражает безумие в самом коде. С нетерпением жду, когда эту хрень всерьёз копнут насчёт дыр - их там будет, не сейчас, так позже - код к поддержке не особо пригоден.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

35. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от Аноним (??) on 12-Май-17, 07:29 
>шифрование трафика - это не то, чем БД должна заниматься

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

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

46. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от пох on 12-Май-17, 12:17 
> Не учи -- не научатся. Все давно придумано: IPSec.

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

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

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

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

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

58. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 12-Май-17, 21:26 
>ну вот покажите мне датацентр, работающий на ipsec - для начала.

Чей ДЦ? Гугла? Вы про что? Гугл может и строит свои ДЦ. Крупный провайдеры строят свои ДЦ. Те, кто умеют в ДЦ могут обойтись MPLS (да-да, ой, сколько оно жрет ресурсов! ути-пути).

>для продолжения - подумайте, сколько ресурсов оно сожрет

Глянь статистику от haproxy. Возьмите статистику от Intel. Средняя температура от 1000 до 50000 тыс. запросов HTTPS в секунду. Последняя цифра на 56 (пятьдесят шесть) ядер на 3ГГц.

Теперь подели эти цифры на кол-во сервисов, которым нужен SSL. А теперь сопоставь с 1-м каналом IPSec на все нужды. Ты математику в школе не прогуливал?

>Ну и еще - шифрование в БД позволяет не изобретать свой велосипед с аутентификацией (в mysql ее пару раз, помнится, ломали)

Ну, все понеслось. Причем тут аутентификация? Кстати, ломали и Oracle DB, если что. Только в БД это ближе к простой авторизации, которая никак не связана с защитой данных. Она нужна для ограничения доступа и прав (что бы левый человек чего что-нибудь под этой учеткой не прочитал аль не записал лишнего). И все.

Сама же аутентификация может быть выполнена на уровне тупого сетевого фильтра (iptables, ipfw, pf). Потому что между ДЦ трафик гоняется от сервера к сервера, а не от пользователя к серверу, где в таком случае аутентификация играет намного большую роль (можно прижать за яйца в случае чего).

>А вот прикрутить готовую ssl - если не заморачиваться сложными ходами - может каждый студент.

Криптография не для студентов. Это отдельная ОГРОМНАЯ область, где от незнания вся безопасность летит к чертям.

Ну, вы продолжайте объяснять как студенты бороздят закаулки криптографии, как они делают _действительно_ секурные вещи и т.п. Очень интересно читать на ночь подобные сказки.

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

59. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 12-Май-17, 21:34 
>1000 до 50000 тыс. запросов

s/1000 до 50000 тыс. запросов/1000 до 50000 запросов/

Да, всего 50 тыс. запросов в секунду.

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

78. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от пох on 15-Май-17, 00:11 
>>ну вот покажите мне датацентр, работающий на ipsec - для начала.
> Чей ДЦ? Гугла? Вы про что?

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

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

> Те, кто умеют в ДЦ могут обойтись MPLS

о, оно слышало про mpls. А теперь расскажи, чего ж это гугль-то не обходится, и запихнул свои mpls'ы внуть шифрованного канала, ась? Вот тупые, да?

> Глянь статистику от haproxy. Возьмите статистику от Intel.

мне совершенно неинтересна средняя температура по больнице. Я спрашивал, как вы себе видите - в ядрах там, в шкафах или как, банальную такую коробку а-ля гугль, шифрующую траффик через вшивенький одиночный 10G - предположим, что он у нас не для красоты, а заполнен процентов на 45. У меня вот их нынче к примеру пара на ДЦ, а мы вовсе не гугль, и вообще застряли в развитии - предполагалось, что их будет штук по восемь. Спецификации соответствующих железок в общем-то существуют в открытом доступе. Правда, моя личная встреча с реальностью в виде таких железок, окончилась некоторым, гхм, фиаско, на потоках на два порядка поменьше - не все что пишут в красивых буклетах, достижимо на деле.

> Ну, все понеслось. Причем тут аутентификация?

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

> Сама же аутентификация может быть выполнена на уровне тупого сетевого фильтра
> (iptables, ipfw, pf)

угу, на каждом сервере, и смотри, ничего не перепутай. Админы локалхостов такие затейники... Помнится, над столом dba'шников у нас висела "простая и наглядная схема связей реплик" - здорово напоминающая паутину.

>> А вот прикрутить готовую ssl - если не заморачиваться сложными ходами - может каждый
>> студент.
> Криптография не для студентов

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

А вот изобретения велосипедов с квадратными колесами - типа замены аутентификации файрволом - верный признак вечного недоучки.

Как и попытка оценивать статистикой хапроксей и прочего _смотрящего_вовне_ хлама реальные объемы (реальный такой пример одной сравнительно небольшой веб-лавочки - на ~150мегабит внешнего траффика cross-DC через арендованные линки - то есть как раз такого, который неплохо бы пошифровать - получалось где-то под 500 - при том что его старались, разумеется, держать минимальным, и из-за цены канала, и из-за rtt, большая часть внутреннего обмена происходила внутри своей стойки.)

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

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

85. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 15-Май-17, 21:34 
>А теперь расскажи, чего ж это гугль-то не обходится, и запихнул свои mpls'ы внуть шифрованного канала, ась? Вот тупые, да?

Ты бы почитал про MPLS. Тебе чтоли все разжевывать надо? Если что, то я имел ввиду MPLS/VPN. Да, там уже само по себе встроен шифрованный канал. Нужен ли в таком случае IPSec дело десятое, т.к. _мало_ кто сможет приобрести _свой_ канал от точки А до точки Б.

Что касается гугла, то они могут воротить такие вещи, которые тебе и не снились. И у них нет вообще вопроса о том, сколько и что жрет. Вообще-то есть, ибо стоимость электро-энергии у них в первой тройке затрат. Ну, куда уж тебе или мне думать о таких "мелочах". Электричество ж дешевое. Когда у тебя максимум 1000 железок.

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

86. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от пох on 17-Май-17, 16:08 
> Ты бы почитал про MPLS.

спасибо, поржал.


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

22. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от qsdg (ok) on 11-Май-17, 21:21 
Раньше гугля и не обязывал внутренний свой трафик между серверами шифровать.
Пока NSA не спалилось, что оно прослушивало их внутренний трафик на международных каналах. С тех пор в срочном порядке всех обязали включить флаг шифрования для внутренних RPC.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

37. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 12-Май-17, 07:36 
>прослушивало их внутренний трафик

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

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

40. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от qsdg (ok) on 12-Май-17, 08:32 
> И что, что прослушивали? У них там пароли в открытом виде чтоли
> передавались? Или письма ген. дира? Ну, тогда это проблема не БД,
> а безопасников, которые все проморгали.

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

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

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

47. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от пох on 12-Май-17, 12:20 
> Раньше гугля и не обязывал внутренний свой трафик между серверами шифровать.

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

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


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

53. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Вареник on 12-Май-17, 16:36 
> Поскольку если NSA сумеет обойтись без их помощи с дешифровкой - кредитов
> под 0% не дадут.

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

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

7. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +1 +/
Сообщение от xm email(ok) on 11-Май-17, 15:41 
Название, конечно, доставляет. Такое, buggy :-D
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Anonim (??) on 11-Май-17, 19:48 
Тараканы и жуки в не очень родственных отношениях
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

23. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –1 +/
Сообщение от qsdg (ok) on 11-Май-17, 21:22 
> Тараканы и жуки в не очень родственных отношениях

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

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

10. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +/
Сообщение от Аноним (??) on 11-Май-17, 16:43 
Каждый считает своим долгом в первый стабильный релиз добавить слова "отказоустойчивый" и "защищенный".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +1 +/
Сообщение от Аноним (??) on 11-Май-17, 21:04 
Почему каждый? Это неправда.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

24. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  +1 +/
Сообщение от qsdg (ok) on 11-Май-17, 21:24 
> Каждый считает своим долгом в первый стабильный релиз добавить слова "отказоустойчивый"
> и "защищенный".

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

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

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

49. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –2 +/
Сообщение от пох on 12-Май-17, 12:55 
> Каждый считает своим долгом в первый стабильный релиз добавить слова "отказоустойчивый"
> и "защищенный".

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

73. "Первый стабильный выпуск отказоустойчивой СУБД CockroachDB"  –2 +/
Сообщение от Zver (??) on 14-Май-17, 15:01 
Прощай Монга и MySQL?
Как оно вообще? Кто-нибудь тестировал, использовал? Действительно ли так хороша, как описывают?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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



  Закладки на сайте
  Проследить за страницей
Created 1996-2017 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor