Alister O: В этастике триггеров нет. Данные он хранит гарантированно, как и любая nosql штука. И интересно, где это про такое пишут?! Одно но. Для того, чтобы правильно по данным бегать, нужно создавать маппинг, что с наскоку сразу не получится.
Для анализа логов (любых) очень хорошо подходит эластик + kibana + logstash. Но это только анализ логов.
Для мониторинга работы сервисов и серверов мы использует collectd (для линукса) + telegraf (windows) + influxdb (база тайм-значений) + kapacitor (слушает базу и реагирует на события) + grafana (отображение данных).
Соответственно получается две независимых системы.
Сергей Протько: все руководства по быстрому старту к популярным web-фреймворкам начинаются со слов: ставим базу данных, создаем класс, определяем поля и вуаля! Где здесь, черт возьми dao и sql?!
Сергей Протько: еще пример, давайте абстрагируемся от явы и хибернейта, вот совсем. Возьмем например руби, питон, го,, нодеджиэс, да тот же пехапе. Весь мир, за редким исключением отдельных индивидов пользуется ORM и не жалуется, пишут все начиная от бложиков и заканчивая системами типа портала госуслуг, и стараются о чистом sql не думать!
Сергей Протько: когда-то я был уверен, что программируя на ассемблере драйвера для os-9, я поступаю правильно. Это продолжалось ровно до тех пор, пока фирма microware не выпустила оптимизирующий компилятор ultra-c. Я просто взглянул на тот ассемблерный код, который он делал из си, такие конструкции с постфиксами, предикатами и косвенной адресацией мне и в страшном сне не снились. А практически полностью перестал писать на ассемблере, когда начал программировать под PPC, там сам ассемблер сделан для автоматической трансляции. Потом я некоторое время писал sql под всяко разно, а потом был хибернейт... И да, я таки взглянул на тот sql, который из него выходил, у меня тут же возникла аналогия! Компиляторы очень часто делают код гораздо лучше, чем человек, просто им надо в этом помогать. И конечно же, если без SQL или ассемблера не обойтись, то руки не нужно себе выворачивать, просто таких случаев стало катастрофически мало!
aol-nnov: другими словами, если использовать rest + json, заморачиваться ни с чем не нужно, а с json-rpc немного поплясать. А результат будет аналогичный. Да и отлаживаться с rest гораздо легче. Ну на напоследок, давайте посмотрим например на всевозможные api от гугла, яндекса, мордокниги и т.д. Кто из них использует json-rpc?
aol-nnov: как минимум тем, что нам сначала нужно принять json, из него взять метод, его параметры, uid вызова, отмапировать метод на метод в коде, вызвать его с передачей параметров, сформировать ответ. В рест же метод и параметры передаются стандартным способом через гет или пост, а ответ - json в произвольной форме. Со стороны js для вызова нужно тоже немного постараться, простой json еще нужно обернуть в метод с параметрами и uid.
Сергей Протько: session.evict(), sesssionFactory.getCache().evictXXX() и statelessSessions решают практически все проблемы с массивными выборками. Ну и на всякий случай - koenserneels.blogspot.ru/2013/03/bulk-fetching-wit...
Ну также можно базу убить и слишком большим sql-запросом, а потом еще пол часа ждать отката транзакций и разблокировки полей/таблиц, и пусть весь мир подождет.
С другой стороны можно и в dom загнать 10 гигабайтный xml с таким же результатом по памяти, а можно и через sax пройтись. Так что если уж про хибернейт, его нужно уметь готовить, как впрочем и все остальное, когда что-то за 10к объектов перещелкивает.
По поводу п5, в большинстве виденных мной случаев это было именно так!
Извиняюсь, но у вас каша в голове.. 1) JDBC ну никак не упрощается до DAO, куда уж проще. 2) ORM не прологику приложения, а именно про модель данных приложения. 3) ORM в большинстве случаев работает очень эффективно, будь то база данных или xml. 4) для вещей типа генерации ответов ORM прекрасно подходит, даже на десятки тысяч объектов. 5) если вам нужно постоянно обновлять все значения в таблице, у вас фиговая модель базы данных и приложения. 6) и даже в этом случае проблем не вижу.
Матвей Устинов: Ну, как бы там тоже нужно одно из eventlen/gevent/Werkzeug. Другой вопрос, что это все под капот упрятано и наружу не торчит. Так что пользуйте.
Dmitry07: это немного разные вещи, один список, где элементы подряд и могут быть одинаковые, а второй -сет, где элементы уникальные, но сортированные. И по скорости добавления, отдачи все это отличается, и по решаемым задачам. А ток да, у васех коллекций практически одинаковые интерфейсы.
Для анализа логов (любых) очень хорошо подходит эластик + kibana + logstash. Но это только анализ логов.
Для мониторинга работы сервисов и серверов мы использует collectd (для линукса) + telegraf (windows) + influxdb (база тайм-значений) + kapacitor (слушает базу и реагирует на события) + grafana (отображение данных).
Соответственно получается две независимых системы.