metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2012-07-01 12:21 pm
Entry tags:

Если не 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

И все равно это же надо выполнять в СУБД, чтобы вся таблица не фетчилась на клиента или апп-сервер.

[identity profile] plumqqz.livejournal.com 2012-07-01 09:36 am (UTC)(link)
Вы бы лучше о совершенстве луноликого думали. Все бы было больше пользы.

[identity profile] yantayga.livejournal.com 2012-07-01 09:44 am (UTC)(link)
Луноликий - это кто?

[identity profile] si14.livejournal.com 2012-07-01 09:59 am (UTC)(link)
Мне видится так:
-если это мелкое прототипное говнишко без сложных запросов, то монга только в путь. Можно даже утешать себя, что она «будет скейлиться».
-если нужны сложные запросы и данных меньше десятков (может быть сотен, но тут уже нужно напрягаться) гигабайт, то 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), то всё будет работать очень круто и магически.

[identity profile] metaclass.livejournal.com 2012-07-01 10:10 am (UTC)(link)
Риак выглядит привлекательно.

[identity profile] metaclass.livejournal.com 2012-07-01 10:10 am (UTC)(link)
Это обязаны знать все!

[identity profile] yantayga.livejournal.com 2012-07-01 10:14 am (UTC)(link)
Так просветите же необразованную деревенщину, ребе!

[identity profile] w00dy.livejournal.com 2012-07-01 10:25 am (UTC)(link)
Ребе, вы ж в курсе о IQueryable. Если ваш линк провайдер умный, то он построит запрос и выполнит его в базе.

[identity profile] nealar.livejournal.com 2012-07-01 10:27 am (UTC)(link)
Нашли, чему завидовать.

[identity profile] metaclass.livejournal.com 2012-07-01 10:46 am (UTC)(link)
Видел я те запросы. Лучше бы их не было.

[identity profile] w00dy.livejournal.com 2012-07-01 10:54 am (UTC)(link)
А что с ними не так? Для простых действий аля "сходить в базу выбрать что-то" вполне хватает.

[identity profile] metaclass.livejournal.com 2012-07-01 10:55 am (UTC)(link)
Для простых случаев и SQL хватает с ADO.NET
Речь о сложных, с 15-этажными джоинами, подзапросами, CTE и группировкой по критерию, введенному юзером )

[identity profile] nealar.livejournal.com 2012-07-01 11:03 am (UTC)(link)
Некоторые даже этому завидуют: http://metaclass.livejournal.com/703593.html
Интересно, есть ли иностранцы, которые так прутся от Удвоенного?

[identity profile] theiced.livejournal.com 2012-07-01 12:13 pm (UTC)(link)
ребе, вы вот тут чота рассуждаете, асид-хуясид. а между тем получили вендорлокин на файрбёрд - ВСЁ, все (фантомные) преимущества ушли сосать хуй.

[identity profile] theiced.livejournal.com 2012-07-01 12:15 pm (UTC)(link)
не нужны 15этажные джоины. они говно.

[identity profile] dr-hyder.livejournal.com 2012-07-01 12:18 pm (UTC)(link)
АутистыЫЫЫ! (http://metaclass.livejournal.com/678493.html?thread=11757917&)

[identity profile] avnik.livejournal.com 2012-07-01 12:21 pm (UTC)(link)
zodb же!
(serialized objects, btree, кровь, кишки, коровники прилагаются. Запросы на питоне)
Правда скейлится на кластер или rdbms backend'ом или за деньги.

[identity profile] dr-hyder.livejournal.com 2012-07-01 12:21 pm (UTC)(link)
Нэт, кауч развалится быстрее к хуям, ответственно заявляю. Riak - будет работаць и не жужжать.

[identity profile] w00dy.livejournal.com 2012-07-01 12:41 pm (UTC)(link)
Вот кстати да. Откуда вообще ноги у файрбёрда растут? из делфей?

[identity profile] w00dy.livejournal.com 2012-07-01 12:43 pm (UTC)(link)
ребе, эти 15 этажные запросы потом никто поддерживать не сможет, не говоря уже о том чтобы разобраться. Не, за много денег конечно разберутся, но проще будет выкинуть к хуям и переписать заново.

[identity profile] berezovsky.livejournal.com 2012-07-01 12:47 pm (UTC)(link)
как вы красиво говорите

[identity profile] stdray.livejournal.com 2012-07-01 12:49 pm (UTC)(link)
А что за наязчивое желание избавится от RDBMS, я никак не пойму? Кривыми ОРМ или как?

[identity profile] alexandr0.livejournal.com 2012-07-01 12:55 pm (UTC)(link)
Сейчас модно посредством nosql :)

[identity profile] dr-hyder.livejournal.com 2012-07-01 01:03 pm (UTC)(link)
Народ осознал что ему в большинстве случаев нужен просто удобный storage с быстрыми простыми запросами и хорошей масштабируемостью. Реляционность это замечательно, но нафиг не нужна.

[identity profile] avnik.livejournal.com 2012-07-01 01:16 pm (UTC)(link)
+1 кстати.
За то время, что нормализуется схема данных, можно уже забацать прототип без sql (да хоть на файлах) и пойти рубиться в квейкпоказать целевой группеинвесторов пользователей

PS Я несколько утрирую, но это так

[identity profile] stdray.livejournal.com 2012-07-01 01:20 pm (UTC)(link)
А ведь если взять тот же мускуль и руками (в своем приложении) распределять данные по разным инстансам мускуля, забыв про джойны всякие, то оно и получится. То есть "просто удобный storage с быстрыми простыми запросами и хорошей масштабируемостью". Или я чего-то не понимаю?

Page 1 of 3