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.11, _ (??), 17:03, 11/05/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Как страшно жить! (С)
Мучайся, Go взлетел и его вокруг будет только больше и больше.
(демоническим голосом) Му-ха-ха-хаа! 8-)
| |
|
5.30, cmp (ok), 01:12, 12/05/2017 [^] [^^] [^^^] [ответить] | +/– | Ага, как и ява, 10 15 лет обещают, что она будет сравнима по скорости с СИ и... большой текст свёрнут, показать | |
|
|
7.34, Аноним (-), 07:25, 12/05/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
>Я в своём кругу видел много сишного софта на array-ях, которое мало ело ОЗУ и было НИКАКОЕ по скорости, по сравнению с могучей жабкой на адекватных стурктурах.
>в своём кругу
Найдите нормально сишнека и не позорьтесь со своими выводами. Хотя нет, позорьтесь, ява головного мозга не лечится.
| |
|
|
9.38, Аноним (-), 07:45, 12/05/2017 [^] [^^] [^^^] [ответить] | +/– | Ваш ограниченное окружение вкупе с правильно мнение -- только мое мнение завед... текст свёрнут, показать | |
|
|
|
|
Часть нити удалена модератором |
13.45, cmp (ok), 12:16, 12/05/2017 [ответить] | +/– | Ява быстрее си, ахахаха, тебя псаки покусала или ты с рождения такой ... текст свёрнут, показать | |
|
14.50, Аноним (-), 13:30, 12/05/2017 [^] [^^] [^^^] [ответить] | +3 +/– | Я думаю что он пишет на Си так что у него всегда Java быстрее работает А понять... текст свёрнут, показать | |
|
|
16.61, Аноним (-), 21:55, 12/05/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Ты действительно думаешь что это честное сравнение Ты либо глуn, либо Береш... большой текст свёрнут, показать | |
|
|
18.72, Аноним (-), 13:01, 14/05/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Ты всегда берешь кассандру без постановки задачи И как связано взятие чего-т... большой текст свёрнут, показать | |
|
|
16.65, cmp (ok), 07:13, 13/05/2017 [^] [^^] [^^^] [ответить] | +/– | Да есть готовые, полно, но на 10к элементов они показывают худшие результаты по ... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
9.69, Ydro (?), 13:47, 13/05/2017 [^] [^^] [^^^] [ответить] | –1 +/– | У меня программирование - домашнее хобби, в итоге Сто раз читал книги по Jave -... текст свёрнут, показать | |
|
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 +/– |
>>Если, вон, Байду использует
> Единственное мое знакомство с этой компанией произошло, когда с рабочего компа мамы
> удалял их аналог мэйл.ру агента. Судя по тому, с каким скрипом
> эта поделка удалялась, делаю вывод, что конторка-то не особо авторитетная. Сказали
> бы, что Яндекс использует - тогда бы стоило обратить внимание.
Яндекс по среавнению с Байду маленькая пупырка.
| |
|
|
|
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.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.78, пох (?), 00:11, 15/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 покупают украденную у пользователей всего мира инфу, а не тупо тырят )))
| |
|
|
|
|
|
|
|
|
3.23, qsdg (ok), 21:22, 11/05/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Тараканы и жуки в не очень родственных отношениях
Да и в холодных странах с тараканами легко справлялись -- уходили зимой ночевать к соседям. Тараканы все замерзали, бедненькие :(
| |
|
|
1.10, Аноним (-), 16:43, 11/05/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Каждый считает своим долгом в первый стабильный релиз добавить слова "отказоустойчивый" и "защищенный".
| |
|
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?
Как оно вообще? Кто-нибудь тестировал, использовал? Действительно ли так хороша, как описывают?
| |
|