VL
для платежек я бы nosql не использовал. по той простой причине, что где есть платежи, там всегда есть репорты. а nosql для репортов плохо подходит
Size: a a a
2021 March 16
AH
для платежек я бы nosql не использовал. по той простой причине, что где есть платежи, там всегда есть репорты. а nosql для репортов плохо подходит
да, я тоже так думаю
AH
платежки лучше в sql кидать, где можно быстро пробежать всякими сканами умными и тоталы, раннинг тоталы и прочие агрегаты по всему на свете собрать
VL
угу
A
для платежек я бы nosql не использовал. по той простой причине, что где есть платежи, там всегда есть репорты. а nosql для репортов плохо подходит
Реляционки тоже плохо
оГ
и вес таблицы x num cases :)
Шашечки или ехать?
DP
А конкуренция как в no sql? Last write wins?
A
А конкуренция как в no sql? Last write wins?
Зависит от базы
A
В riak можно и lww и самому разрешать конфликты
VL
Реляционки тоже плохо
ну а больше и негде
A
ну а больше и негде
clickhouse - не реляционка.
VL
из вики
VL
Однако при этом имеются и ограничения — отсутствие транзакций, отсутствие точечных UPDATE/DELETE (пакетный UPDATE/DELETE был введен в июне 2018 года), ограниченная поддержка синтаксиса JOIN, строгие типы с необходимостью явного приведения, для некоторых операций промежуточные данные должны помещаться в оперативную память, отсутствие оконных функций, отсутствие полноценного оптимизатора запросов, точечного чтения, присутствие ограничений в реализации некоторых функций, связанных со спецификой использования ClickHouse в Яндексе, и т. д.
VL
вообще, очень похоже на nosql, только данные сериализуются не в json, а в столбец в таблице
A
вообще, очень похоже на nosql, только данные сериализуются не в json, а в столбец в таблице
Многие column oriented storage такие. Я, в целом делал доклад обзорный на эту тему. О том, что такое nosql, и во что оно превратилось в настоящем.
В
Однако при этом имеются и ограничения — отсутствие транзакций, отсутствие точечных UPDATE/DELETE (пакетный UPDATE/DELETE был введен в июне 2018 года), ограниченная поддержка синтаксиса JOIN, строгие типы с необходимостью явного приведения, для некоторых операций промежуточные данные должны помещаться в оперативную память, отсутствие оконных функций, отсутствие полноценного оптимизатора запросов, точечного чтения, присутствие ограничений в реализации некоторых функций, связанных со спецификой использования ClickHouse в Яндексе, и т. д.
интересно а в чем проблема точечного чтения?
RM
БД на f#?
V
вообще, очень похоже на nosql, только данные сериализуются не в json, а в столбец в таблице
Это ж и есть nosql. Колоночная БД.
Просто для удобства есть sql-интерфейс
Просто для удобства есть sql-интерфейс