+1, у нас ежесуточно приходит отчет по query digest
если кстати появится инструментарий который позволит смотреть такие отчеты более наглядно, я его пожалуй куплю =)
отличная статья! очень хороший пример практического применения… спасибо большое, от нее буду отталкиваться в своих изысканиях по кластеризации и по forecast анализу…
=)) даже не знаю, никогда визуальным Query Builder не пользовался
всегда хватала мозгов чтобы сделать запросы руками =)
там где не хватало
делал через временные таблицы или view'ки
=)) ну и еще… можно несколько запросов в открытой транзакции в консоли делать… и SELECT'ом проверять что все правильно заапдейтили…
а потом уже делать COMMIT или ROLLBACK ;)
собственно говоря, теперь же вы просто будете внимательнее работать с консолью…
все когда то делают свой первый «неправильный UPDATE» ;)
конкуретное обновление в данном случае не требуется, при добавлении сообщения, в DynamoDB просто добавляются Item по HashKey для соответсвующего dialogID
максимум требуется атомарный инкремент (если хранить длину сообщения)…
его можно сделать через внешние локи по ключу (опять же dialogID например на redis), но нагрузка не настолько большая…
а с учетом того что сервер nodejs одно-поточный и используется nodejs+sockjs… то возникновение необходимости обновить кол-во сообщений в диалоге одновременно от двух клиентов, очень мала
если говорить про DynamoDB то там все просто, это не ACID хранилище и консистентности там нет, зато очень высокая доступность и низкая latency, достаточно стоимость низкая (по сравнению с остальными сервисами типа EC2 или RDS) и приемлимое API для определенного вида выборок =)
только написал и оказывается есть целый пласт инструментов! надо пробовать…
если кстати появится инструментарий который позволит смотреть такие отчеты более наглядно, я его пожалуй куплю =)
www.dbmaestro.com/products-solutions/demo/
digitaloctober.ru/ru/events/perezapusk_2gis
всегда хватала мозгов чтобы сделать запросы руками =)
там где не хватало
делал через временные таблицы или view'ки
и еще толпа query builder'ов делают тоже самое
вообще на самом деле не хватает какого нибудь дешевого шараварного аналога Tabeau с помесью с FastReport server ;)
partizan-info.com/product/
(с) Мосяня =)
а потом уже делать COMMIT или ROLLBACK ;)
собственно говоря, теперь же вы просто будете внимательнее работать с консолью…
все когда то делают свой первый «неправильный UPDATE» ;)
максимум требуется атомарный инкремент (если хранить длину сообщения)…
его можно сделать через внешние локи по ключу (опять же dialogID например на redis), но нагрузка не настолько большая…
а с учетом того что сервер nodejs одно-поточный и используется nodejs+sockjs… то возникновение необходимости обновить кол-во сообщений в диалоге одновременно от двух клиентов, очень мала
если говорить про DynamoDB то там все просто, это не ACID хранилище и консистентности там нет, зато очень высокая доступность и низкая latency, достаточно стоимость низкая (по сравнению с остальными сервисами типа EC2 или RDS) и приемлимое API для определенного вида выборок =)
и что вы подразумеваете под этим словом?
в чем заключаются на ваш взгляд «проблемы»?
я думаю лучше www.phpReact.org ;) он интереснее
возможно вы перешли по ссылке https://