Я не ленюсь в этом плане — у готовых omnibus'ов есть свои недостатки, особенно что касается экстренных обновлений Ruby и всяких Security патчей. Количество съеденной оперативки от способа установки не зависит. В omnibus'e те же исходники и теже init скрипты, и тот же костыль на перезапуск sidekiq по таймауту и в случае съедения всей памяти.
Единственной причиной по которой я до недавних пор пользовался gitlab'ом являлось наличие хорошего ci.
Сейчас же можно спокойно пользоваться https://github.com/drone/drone c gogs'ом.
Некорректно сравнивать Camel с Flume так как задачи совсем различные: Flume разрабатывался для потоковой обработки логов в конвейерах, а Camel для преобразования разнородных интерфейсов.
Для проектов «со стажем» это будет общепринятой практикой и соответствующее соглашение будет утверждено документально, что бы упростить поддержку и внедрение нового функционала. Не будет ситуаций: кто что захотел, пришёл и наворотил — потому что захотел, а не потому что надо.
В данном случае при определении пути stations/1/arrivals учитывается что у вас OneToMany отношение со сложенным ключем.
Если у таблички Arrivals PK состоит из ID и FK station_id, то целесообразно использование
stations/{station_id}/arrivals/{arrival_id}
Если у таблички Arrivals PK состоит только из ID, то можно и
/arrivals/{arrival_id}
которые при поиске по станции будут выглядеть так
/arrivals/station/{station_id}
Сложенные ключи позволяют упростить жизнь если таблички будут расти до непонятных размеров (200Гб — 2Тб), в последствии шардиться и партицироваться, дампиться во внешнее хранилище (cassandra / hbase etc) или архивные таблички (mysql engine archive).
Так что это скорее вопрос разработки и нормализации доменной модели, чем интерфейсов…
p.s. нормальных форм нынче уже шесть
Мир на Swagger'e не заканчивается — у него тоже недостатков хватает.
Думаю было бы не плохо упомянуть про HATEOAS подход и довольно плачевную ситуацию с существующими протоколами на этом поприще.
Сейчас разрабатывается пару довольно интересных подходов к разработке реактивных приложений, без использования вышеупомянутых boilerplate'ов и без кодогенерации.
Я не говорю что протрактор плох, или что его не стоит использовать, я просто не вижу смысла использовать его с Java/Net, и есть решения гораздо эффективнее (jsdom). Почти все известные мне фронтендеры пишут приёмочные тесты сами под себя на JS'е. Бэкенд с REST эндпоинтами имеет смысл покрывать тестами на C#/Java в случае реализации гипермедиатипов (hateoas), кодогенерации, или шаблонных контроллеров.
Можете пожалуйста аргументировать вашу точку зрения: почему кому-то стоит использовать E2E тестирование для JS проекта на С#/Java?
Лучше уж JSDOM для E2E тестирования использовать, а не Selenium суррогаты.
Фронтендерам проще самостоятельно покрывать свой JS фронтенд тестами на JS'е, и не зависить от разработчиков бэкенда, на чём бы он не был написан. По этому я считаю нецелесообразным портировать тот же protractor под C# или что либо другое.
B-дерево может применяться для структурирования (индексирования) информации на жёстком диске (как правило, метаданных). Время доступа к произвольному блоку на жёстком диске очень велико (порядка миллисекунд), поскольку оно определяется скоростью вращения диска и перемещения головок. Поэтому важно уменьшить количество узлов, просматриваемых при каждой операции. Использование поиска по списку каждый раз для нахождения случайного блока могло бы привести к чрезмерному количеству обращений к диску, вследствие необходимости осуществления последовательного прохода по всем его элементам, предшествующим заданному; тогда как поиск в B-дереве, благодаря свойствам сбалансированности и высокой ветвистости, позволяет значительно сократить количество таких операций.
Потому что B-tree, по определению, хранит ключи которые определяют отношение между существующими сущностями, это помогает получить неглубокое дерево, первые 2-3 три уровня ключей которого могут хранится в оперативке, а остальные на винте. Что собственно позволяет значительно уменьшить количество дисковых операций. Ещё там фигурируют разнообразные cache-oblivious вещи, но это уже тема отдельной статьи.
Так как информация которую хранит B-tree априори требует определения отношений между существующими сущностями — любую СУБД, которая использует его для индексации, можно назвать реляционной.
Если сравнивать с другими структурами, типа lsm-tree(sstable) / R-tree / X-tree / MVP-tree / Fusion-tree, то у них совсем другие задачи, они не хранят отношений и их ключи используются сугубо для адресации. Соответственно их использование совсем не связано с реляционными моделями.
Если почитать офф доки PostgreSQL'я http://www.postgresql.org/docs/9.5/static/functions-json.html
То станет понятно что там происходит ручная распаковка jsonb в один из существующих типов, можно даже в табличку или в представление, после чего можно выполнять любые доступные запросы.
Есть полнотекстовый поиск и GIN индекс — они себя обычно ведут шустрее простого B-tree.
Если почитать прошлогодний https://www.pgcon.org/2014/schedule/events/696.en.html CREATE INDEX… USING VODKA, то это в принципе должно быть очевидно.
Если читать внимательно хабр, недавно выходила серия (4шт) хороших статей от the_unbridled_goose о специфике разработки документ-ориентированного API на PostgreSQL.
Бэнчмарк чуть морально устарел, уже есть MongoDB 3.2, c нормальным MVCC.
Горизонтальное масштабирование у MongoDB это большой и толстый кот в мешке, с кучей заморочек, и их не меньше чем у PostgreSQL'я.
По производительности на одну ноду, понятное дело, лидирует PostgreSQL.
Мне вот один товарищ с пеной изо рта пытался доказать что MongoDB это «нереляционная, документо-ориентированная БД» — если бы это было бы действительно так, то в ней бы не использовался банальный B-tree индекс и она не подчинялась бы всем существующим правилам нормализации. По этому разводить документо-ориентированный трёп нет особо то и смысла — это выдуманное понятие, не более чем маркетинговый трюк для привлечения инвестиций.
Нужно понимать что MongoDB строилась по принципу: мы придумаем много новых умных слов, скажем что, мол, такие все инновационные NoSQL подонки, и пофигу что оно нифига не работает, — на нас ведь посыпется дождик вечнозелёных от наивных инвесторов, потом может когда-то починим, если будут громко орать и пускать лучи ненависти. И да, чинят, на самом деле, очень неохотно.
Извините, если оскорбил чувства свято верующих в бесконечное и неосязаемое величие MongoDB, считаю что пора вам спускаться на землю.
Наличие списка API функций и их аргументов отнють не гарантирует отсутствие дыр непосредственно в самой реализации.
Намеренное переполнение буферов, со всеми последствиями, никто не отменял.
На сколько я понял Realm – это проприетарное решение за 0$, с опенсорсными байндингами к Java и Cocoa в которое всё дружно грузят данные своих приложений.
Это звучит хорошо и красиво, но в чём подвох?
С точки зрения безопасности подключение подобных библиотек может сулить довольно большой брешью.
Не то что бы я был прям таким «большой брат...» и всё такое, но вот если какие-то весёлые ребята найдут что-то и будут сливать платёжную информацию — будет весело.
У CPLD плотность выше так как ячейки попроще, и с тем же тех процессом можно впихнуть больше.
А для трейдеров всякие DSP и прочие сигнало-непотребства, характерные для FPGA, — не нужны, по этому их целесообразно порезать. Да и режут не полностью, часть LUT'a остаётся FPGA'шной. Да и выхлоп качественных FPGA после травки вафли стремится к нулю, а вот с CPLD ситуация проще так как потеря даже 30% ёмкости погоды не сделает — в массовом производстве обходится дешевле минимум в 2-3 раза.
ASIC'и нужно руками собирать по кусочкам, автоматизированные трассировщики могут очень много шлака инкрустировать.
По этому бывают очень часто случаи когда ванильное FPGA гораздо шустрее плохо спроектированного ASIC'a, по моим личным наблюдениям это где-то 6 из 10 проектов :)
btw сейчас очень часто для HFT используют Virtex 7 и заказывают обрезку FPGA до CPLD у самого Xillinx'a, вместо изготовления ASIC'ов.
http://www.jessicasandhu.com/wp/wp-content/uploads/2015/05/EinsteinHatersGonnaHate-e1430891648587.jpg
Единственной причиной по которой я до недавних пор пользовался gitlab'ом являлось наличие хорошего ci.
Сейчас же можно спокойно пользоваться https://github.com/drone/drone c gogs'ом.
Довольно сложная установка и потребность в RVM'e.
Если у таблички Arrivals PK состоит из ID и FK station_id, то целесообразно использование
stations/{station_id}/arrivals/{arrival_id}
Если у таблички Arrivals PK состоит только из ID, то можно и
/arrivals/{arrival_id}
которые при поиске по станции будут выглядеть так
/arrivals/station/{station_id}
Сложенные ключи позволяют упростить жизнь если таблички будут расти до непонятных размеров (200Гб — 2Тб), в последствии шардиться и партицироваться, дампиться во внешнее хранилище (cassandra / hbase etc) или архивные таблички (mysql engine archive).
Так что это скорее вопрос разработки и нормализации доменной модели, чем интерфейсов…
p.s. нормальных форм нынче уже шесть
Думаю было бы не плохо упомянуть про HATEOAS подход и довольно плачевную ситуацию с существующими протоколами на этом поприще.
Сейчас разрабатывается пару довольно интересных подходов к разработке реактивных приложений, без использования вышеупомянутых boilerplate'ов и без кодогенерации.
Можете пожалуйста аргументировать вашу точку зрения: почему кому-то стоит использовать E2E тестирование для JS проекта на С#/Java?
Фронтендерам проще самостоятельно покрывать свой JS фронтенд тестами на JS'е, и не зависить от разработчиков бэкенда, на чём бы он не был написан. По этому я считаю нецелесообразным портировать тот же protractor под C# или что либо другое.
Может стоит научится читать, хотя бы википедию?
Так как информация которую хранит B-tree априори требует определения отношений между существующими сущностями — любую СУБД, которая использует его для индексации, можно назвать реляционной.
Если сравнивать с другими структурами, типа lsm-tree(sstable) / R-tree / X-tree / MVP-tree / Fusion-tree, то у них совсем другие задачи, они не хранят отношений и их ключи используются сугубо для адресации. Соответственно их использование совсем не связано с реляционными моделями.
То станет понятно что там происходит ручная распаковка jsonb в один из существующих типов, можно даже в табличку или в представление, после чего можно выполнять любые доступные запросы.
Если почитать прошлогодний https://www.pgcon.org/2014/schedule/events/696.en.html CREATE INDEX… USING VODKA, то это в принципе должно быть очевидно.
Если читать внимательно хабр, недавно выходила серия (4шт) хороших статей от the_unbridled_goose о специфике разработки документ-ориентированного API на PostgreSQL.
Горизонтальное масштабирование у MongoDB это большой и толстый кот в мешке, с кучей заморочек, и их не меньше чем у PostgreSQL'я.
По производительности на одну ноду, понятное дело, лидирует PostgreSQL.
Мне вот один товарищ с пеной изо рта пытался доказать что MongoDB это «нереляционная, документо-ориентированная БД» — если бы это было бы действительно так, то в ней бы не использовался банальный B-tree индекс и она не подчинялась бы всем существующим правилам нормализации. По этому разводить документо-ориентированный трёп нет особо то и смысла — это выдуманное понятие, не более чем маркетинговый трюк для привлечения инвестиций.
Нужно понимать что MongoDB строилась по принципу: мы придумаем много новых умных слов, скажем что, мол, такие все инновационные NoSQL подонки, и пофигу что оно нифига не работает, — на нас ведь посыпется дождик вечнозелёных от наивных инвесторов, потом может когда-то починим, если будут громко орать и пускать лучи ненависти. И да, чинят, на самом деле, очень неохотно.
Извините, если оскорбил чувства свято верующих в бесконечное и неосязаемое величие MongoDB, считаю что пора вам спускаться на землю.
Намеренное переполнение буферов, со всеми последствиями, никто не отменял.
Это звучит хорошо и красиво, но в чём подвох?
С точки зрения безопасности подключение подобных библиотек может сулить довольно большой брешью.
Не то что бы я был прям таким «большой брат...» и всё такое, но вот если какие-то весёлые ребята найдут что-то и будут сливать платёжную информацию — будет весело.
А для трейдеров всякие DSP и прочие сигнало-непотребства, характерные для FPGA, — не нужны, по этому их целесообразно порезать. Да и режут не полностью, часть LUT'a остаётся FPGA'шной. Да и выхлоп качественных FPGA после травки вафли стремится к нулю, а вот с CPLD ситуация проще так как потеря даже 30% ёмкости погоды не сделает — в массовом производстве обходится дешевле минимум в 2-3 раза.
По этому бывают очень часто случаи когда ванильное FPGA гораздо шустрее плохо спроектированного ASIC'a, по моим личным наблюдениям это где-то 6 из 10 проектов :)
btw сейчас очень часто для HFT используют Virtex 7 и заказывают обрезку FPGA до CPLD у самого Xillinx'a, вместо изготовления ASIC'ов.