| |
| |
| 2.10, Добрый (?), 09:12, 12/07/2016 [^] [ответить] [к модератору]
| +/– |
Основная проблема ориентдб в очень низкой надежности. По этому показателю ее обходят едва ли не все конкуренты.
|  | | |
| |
| 3.12, Аноним (5), 09:23, 12/07/2016 [^] [ответить] [к модератору]
| –1 +/– |
А какого рода низкая надёжность имеется ввиду?
Для меня ненадёжность - это когда приходится сбрасывать вручную блокировки с таблиц в MySQL при резком не запланированном отключении электричестве.
|  | | |
| |
| 4.20, Добрый (?), 13:16, 12/07/2016 [^] [ответить] [к модератору]
| +2 +/– |
Элементарная надежность, хотя бы на уровне заявленных гарантий ACID. Почитайте багтрекер ориента и отзывы пользователей на просторах сети. Данная СУБД к продакшену просто не готова.
| | | |
|
|
| 2.33, MMx (?), 10:27, 13/07/2016 [^] [ответить] [к модератору]
| +/– |
Я остановился на Arango - после всяких neo4j и orient.
Сейчас и эту поделку пощупаем.
| | | |
|
| 1.17, Uri (??), 12:20, 12/07/2016 [ответить] [показать ветку] [···] [к модератору]
| +/– | |
> результаты отдаются в формате JSON
:facepalm:
Ну зачем, зачем json??? Я не понимаю, нахрена всовывать неизвлекаемый сериализатор-десериализатор в говенный формат на выходе запроса?
| | | |
| |
| 2.21, rob pike (?), 14:34, 12/07/2016 [^] [ответить] [к модератору]
| –1 +/– |
Вы плохо читали, она для GraphQL. Который нужен только в client-side javascript. Которому в качестве данных было бы очень странно отправлять что-то кроме JSON.
| | | |
| |
| |
| 4.24, rob pike (?), 14:56, 12/07/2016 [^] [ответить] [к модератору]
| +/– | |
Графовые данные и GraphQL это примерно как энтерпрайз и ASP.NET.
GraphQL нужен только и исключительно веб-фронтенду. При этом никакая графовость там совершенно не нужна, нужна возможность не бегать к суровым DBA на каждый чих и не просить тех добавить три поля в запрос - что требуется каждые пять минут в соответствии с TDD, Agile, Scrum и окончательным вытеснением Waterfall вместе с какими-либо попытками проектирования чего-либо.
Графовые БД тоже нужны далеко не всем, но когда нужны, используют что-то серьезнее - например, AllegroGraph.
| | | |
| |
| 5.27, MPEG LA (ok), 16:41, 12/07/2016 [^] [ответить] [к модератору]
| +/– |
я так понимаю, вы перечислили все страшные слова которые знали.
GraphQL разрабатывался в первую очередь для мобильных устройств.
|  | | |
| |
| |
| 7.35, MPEG LA (ok), 13:12, 13/07/2016 [^] [ответить] [к модератору]
| –1 +/– |
столько текста, и сплошной субъективизм. тема почему "GraphQL нужен только и исключительно веб-фронтенду" не раскрыта. GraphQL вполне применим и внутри микросервисов, и на мобилках, и для десктопных клиент-серверных.
| | | |
| |
| 8.36, rob pike (?), 01:15, 14/07/2016 [^] [ответить] [к модератору]
| +/– | |
Не субъективизм, а глубочайшее и подробнейшее рассмотрение онтологической сущности технологии, её области применимости, и проблематики, вызвавших её появление, в комплексе, включая наиболее важные - управленческие и социальные - аспекты современной командной разработки.
Веб-фронтенд действительно можно обобщить до любых аджайло-сервисов в условиях взаимной ненависти разных команд разработчиков, вызванных отсутствием вменяемого управления ими.
| | | |
|
|
|
| 5.30, Crazy Alex (ok), 18:10, 12/07/2016 [^] [ответить] [к модератору]
| +1 +/– | |
Ну вот мне, напрмиер, нужно что-то несерьёзное - на десктоп, для локального применения. Чтобы разложить... скажем, документы по иерархическим тегам. То есть документ может иметь несколько тегов, а теги могут быть вложены друг в друга. В идеале - у тега может быть больше одного родителя. Чтобы на этом работали запросы с приемлемой скокростью хотя бы на паре десятков тысяч документов и стольких же тегах - с релционкой надо как-то очень странно извращаться, а от нескольких родителей у тега - отказываться.
P.S. Ты бы agile с отсутствием планирования не путал. Там всего и делов - не пытаться планировать то, для чего нет данных.
|  | | |
| |
| 6.32, rob pike (?), 08:39, 13/07/2016 [^] [ответить] [к модератору]
| +/– | |
Почему только документы? Окна, например, я бы тоже с радостью разложил по иерархическим тэгам. И не только окна. Но нечем, все заняты переписыванием hello world на Go и Rust.
Я не вижу кейса когда у одного тэга больше одного родителя имело бы смысл, покажете?
С Agile невозможно ничего спутать, ведь известно что любое утверждение про Agile всегда можно признать неверным, "потому что это неправильный Agile, в правильном Agile всё не так" - ровно как с социализмом.
| | | |
| |
| 7.37, Crazy Alex (ok), 09:14, 14/07/2016 [^] [ответить] [к модератору]
| +/– | |
Когда начинаешь раскладывать документы оказывается, что есть несколько параллельных классификаций. Вот, например, есть тег "Гитлер". Он может попадать в родительские категории "нацизм", "диктаторы" и "немецкие политические деятели". Либо надо делать теги без иерархии, и каждому документу добавлять по 100500 (пусть и с автоматизацией), а выбирать потом исключительно запросами на пересечение - но одноранговые теги плохи по другим причинам в перву. очередь их просто помнить/просматривать неудобно, как только количество улетает за третью сотню. А учитывая, что подобный софт имеет смысли именно для боьших массивов - три сотни - ни разу не предел.
Насчёт агайла - не знаю, правильный или нет агайл там, где я работаю, но что хрен там получится спланировать надолго - факт. Потому что, во-первых, надо учитывать хотелки заказчиков, некоторые - весьма срочные, во-вторых - эволюцию возможностей девайсов и их операционок (проект для мобил), в-третьих - фичи конкурентов, в-четвёртых - изменения тех, с кем интегрируешься. В результате как там можно что-то спланировать больше, чем месяца на три - даже не представляю.
| | | |
|
|
|
|
|
|
| |
| 2.25, rob pike (?), 14:59, 12/07/2016 [^] [ответить] [к модератору]
| +/– | |
В лучшем случае типичный слой "бизнес-логики" в вебе (где и нужен GraphQL) занимается просто заворачиванием резалтсетов в JSON, в худшем - еще и императивным вытягиванием всей БД и проходами по ней в циклах тройной вложенности перед этим.
Никаких MVC и MVVM в этом всем обычно не наблюдается.
| | | |
|
| |
| |
| 3.31, all_glory_to_the_hypnotoad (ok), 22:21, 12/07/2016 [^] [ответить] [к модератору]
| +1 +/– | |
protobuf это не протокол. Как формат сериализации он так себе и уж совсем гогно все его родные гугловые библиотеки с реализацией парсеров и генераторов. Для повседневных затычек внутри компании он более-менее годится и только.
> Или это о gRPC?
Раз уж gRPC прибит к протобуфу, то и о нём, естественно, тоже. Самое удивительное, что оно ещё умудряется отдавать ответы в JSON.
Делаете протокол на основе HTTP - ну так используйте все типичные для этого протокола методы передачи запросов, т.е. текстовые аргументы которые можно набирать руками и ответамы в JSON/XML. Иначе же нет смысла прибивать протокол к транспорту поверх HTTP, свои реализации поверх сырого сокета дают больше профита.
|  | | |
| |
| 4.34, АнонимХ (ok), 11:55, 13/07/2016 [^] [ответить] [к модератору]
| +/– | |
> protobuf
Чем плохи гугловские либы? Показывают неплохую производительность, с глюками не сталкивался. Я серьезно спрашиваю. А альтернативы?
|  | | |
| |
| 5.39, all_glory_to_the_hypnotoad (ok), 03:34, 15/07/2016 [^] [ответить] [к модератору]
| +/– |
Не могут парсить пакеты в потоковом режиме, читают сразу всё в память делая кучу аллокаций даже если данные нахрен не нужны. Есть довольно низкие ограничения на размер пакета, порядка максимум полугига, но рабочие размеры несколько сотен мб. Причём сам парсер может понаделать UB если таки уговорить его сжирать большие пакеты. Альтернативой всему этому будет что-то типа flatbuffers.
| | | |
|
| 4.38, Crazy Alex (ok), 01:55, 15/07/2016 [^] [ответить] [к модератору]
| +/– | |
Ты можешь как-то аргументированно ответить? Куче народу было бы полезно. А то "гогно" информативностью не блещет.
Я вот знаю, что третий протобуф шустр и сравнительно компактен.
Почему нельзя поверх сокета - понятно, надо, чтобы браузерные клиенты дёргать могли.
| | | |
| |
| 5.40, all_glory_to_the_hypnotoad (ok), 03:38, 15/07/2016 [^] [ответить] [к модератору]
| +/– | |
> Почему нельзя поверх сокета - понятно, надо, чтобы браузерные клиенты дёргать могли.
Что за бред несёшь ... протобуф в браузере офигеть как удобно готовить. Для браузера делают отдельные гейтвеи, а не костылят эту проблему в протоколе общения с СУБД.
| | | |
|
|
|
|
|
|
