![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Если не RDBMS, то что?
http://metaclass.livejournal.com/706440.html?thread=13096072#t13096072
Можно ли делать опердени не на RDBMS, не возвращаясь на уровень 70х годов, с иерархическими базами и прочими обработками на клиенте по курсорам?
Вариант "есть транзакции с ACID и есть оптимизированное по индексам выполнение filter/map/fold/reduce внутри базы" меня в принципе устроит. За исключением того, что SQL более лаконичен, вроде бы, если не делать внутри языка DSL аналогичный ему.
Например: select User_Name from Users where User_ID=?User_ID превращается во что-то вроде
let UserName UserID =
Users |> filter (fun u -> u.User_ID=UserID) |> map (fun u->u.User_Name) |> tryFirst
На LINQ же будет что-то вроде: from u in Users where u.User_ID=User_ID select u.User_Name
И все равно это же надо выполнять в СУБД, чтобы вся таблица не фетчилась на клиента или апп-сервер.
Можно ли делать опердени не на RDBMS, не возвращаясь на уровень 70х годов, с иерархическими базами и прочими обработками на клиенте по курсорам?
Вариант "есть транзакции с ACID и есть оптимизированное по индексам выполнение filter/map/fold/reduce внутри базы" меня в принципе устроит. За исключением того, что SQL более лаконичен, вроде бы, если не делать внутри языка DSL аналогичный ему.
Например: select User_Name from Users where User_ID=?User_ID превращается во что-то вроде
let UserName UserID =
Users |> filter (fun u -> u.User_ID=UserID) |> map (fun u->u.User_Name) |> tryFirst
На LINQ же будет что-то вроде: from u in Users where u.User_ID=User_ID select u.User_Name
И все равно это же надо выполнять в СУБД, чтобы вся таблица не фетчилась на клиента или апп-сервер.
no subject
-если это мелкое прототипное говнишко без сложных запросов, то монга только в путь. Можно даже утешать себя, что она «будет скейлиться».
-если нужны сложные запросы и данных меньше десятков (может быть сотен, но тут уже нужно напрягаться) гигабайт, то RDBMS это прелестно. Серьёзно, какой смысл изобретать велосипед? SQL отличный язык, работает всё быстро, все грабли, которые можно было, уже давно пройдены (по крайней мере если это постгря/мс/оракл, а не какой-нибудь файрбёрд, да).
-если данных уже сильно больше (сотни гигабайт) и много записи (потому что все приличные RDBMS умеют делать кластер с одним записывающим и пачкой отвечающих на чтение), то только тогда стоит думать обо всяких хадупах сотоварищи, потому что запросы писать будет ощутимо сложнее и поддерживать всё это тоже.
Ну и есть две маргинальные технологии не для всех случаев, использующие eventual consistency:
-CouchDB. Вкратце: хранятся иерархические документы а-ля JSON; на все ноды можно писать, со всех нод можно читать; во всех запросах на модификацию должна присутствовать старая версия документа, по ней сервер делает дельту и прицепляет к ней время; каждая нода делает паблиш всех таких дельт на все остальные ноды, из-за этого, с одной стороны, сильно уменьшается промежуток, в который можно прочитать «старые данные», а с другой нагрузка на ноды растёт линейно с количеством нод, поэтому кластеризация служит только для повышения надёжности, а не для улучшения скорости. Поэтому это крутая штука, которая реально «магически» работает со случаями вроде «у нас инстанс кауча на телефоне полностью автономный, делаем любые вообще модификации, подключаемся к сети и всё автоматически консистентно сливается, все конфликты разруливаются по принципу "кто последний тот и прав"». Проблема только в том, что это всё не рассчитано на сотни гигабайт данных и большие нагрузки, а сложные запросы можно делать только мапредьюсом на JS, что не очень круто и не очень быстро.
-Riak. Eventual consistency в дистиллированной форме; по сути это просто движок для CRDT (Commutative Replicated Data Types — типы данных, которые всегда можно слить между собой, независимо от порядка модификации. Например, set без операции удаления или логи — сколько бы нод отдельно друг от друга не писало, всегда можно слить между собой). При этом из коробки балансировка нод, балансировка между консистентностью записи, консистентностью чтения и latency, механизм для автоматического нахождения конфликтов (vector clocks). Хорошо масштабируется в смысле увеличения производительности от количества нод (впрочем, с помощью механизма балансировки консистентности можно сделать аналог кауча с гарантированной консистентностью — например, можно сделать операцию чтения не завершающейся до тех пор, пока все ноды не получат свою копию данных). Не очень хорошо со сложными запросами (снова MapReduce на JS). Есть из коробки индексирование по произвольным полям, но работает не очень. Соль же в том, что если данные являются CRDT (key-value c last writer wins, кстати, является CRDT), то всё будет работать очень круто и магически.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
А это очень спорное высказывание, требующее массу уточнений, начиная с кусков, для которых достаточно eventual consistency, заканчивая необходимыми структурами и выборками.
По сравнению с, нормальные SQL'ины делают многие и сложные выборки весьма и весьма неплохо. И не нужно задумываться о реализации такой структуры, которая бы такие выборки делала быстро. И если потребуется ещё какая выборка, то тоже особенно думать не нужно. И тем более, переделывать.
no subject
Впрочем, меня больше интересует вопрос, как у них репликация теоретически устроена.
no subject
no subject
no subject
no subject