Если не RDBMS, то что?

[metaclass]

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

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

Comments

[plumqqz.livejournal.com]

Вы бы лучше о совершенстве луноликого думали. Все бы было больше пользы.

[yantayga.livejournal.com]

Луноликий - это кто?

[metaclass.livejournal.com]

Это обязаны знать все!

[nealar.livejournal.com]

Нашли, чему завидовать.

[si14.livejournal.com]

Мне видится так:
-если это мелкое прототипное говнишко без сложных запросов, то монга только в путь. Можно даже утешать себя, что она «будет скейлиться».
-если нужны сложные запросы и данных меньше десятков (может быть сотен, но тут уже нужно напрягаться) гигабайт, то 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), то всё будет работать очень круто и магически.

[metaclass.livejournal.com]

Риак выглядит привлекательно.

[dr-hyder.livejournal.com]

Нэт, кауч развалится быстрее к хуям, ответственно заявляю. Riak - будет работаць и не жужжать.

[andrew kondratovich (from livejournal.com)]

Риак был был конфеткой, если бы нормальные индексы запилили.

[w00dy.livejournal.com]

Ребе, вы ж в курсе о IQueryable. Если ваш линк провайдер умный, то он построит запрос и выполнит его в базе.

[metaclass.livejournal.com]

Видел я те запросы. Лучше бы их не было.

[theiced.livejournal.com]

ребе, вы вот тут чота рассуждаете, асид-хуясид. а между тем получили вендорлокин на файрбёрд - ВСЁ, все (фантомные) преимущества ушли сосать хуй.

[w00dy.livejournal.com]

Вот кстати да. Откуда вообще ноги у файрбёрда растут? из делфей?

[avnik.livejournal.com]

zodb же!
(serialized objects, btree, кровь, кишки, коровники прилагаются. Запросы на питоне)
Правда скейлится на кластер или rdbms backend'ом или за деньги.

[stdray.livejournal.com]

А что за наязчивое желание избавится от RDBMS, я никак не пойму? Кривыми ОРМ или как?

[alexandr0.livejournal.com]

Сейчас модно посредством nosql :)

[dr-hyder.livejournal.com]

Народ осознал что ему в большинстве случаев нужен просто удобный storage с быстрыми простыми запросами и хорошей масштабируемостью. Реляционность это замечательно, но нафиг не нужна.

[metaclass.livejournal.com]

Да вот, айсед имеет такое мнение, пытаюсь понять, может я чего упустил и давно нужно опять опердени делать ручным суммированием отчетов через map-reduce.

[norguhtar.livejournal.com]

Господя и вы туда же. Ну вот где-то год назад одни товарищи делали такую же вариацию. Типа ой это удобнее. В результате получите опять же тот же SQL вид в профиль. Вообще говоря текущая проблема вида используем ORM и т.п. подобное не более чем проблема текущей абстракции. Когда с одной стороны у нас есть объектный язык, а с другой стороны хранилище с декларативным доступом к данным. Попытки сделать объектные базы данных предпринимались еще до появления модного термина NoSQL. Тот же Cache. Только вот есть маленькая проблема. Как только доходили до такой вещи "а как бы нам там ловко получить аналитику?" возникал ад и коровники.

[guamoka.livejournal.com]

Мои сугубо личные притензии к SQL - это отсутствие реюза. Точнее, внятной модели осуществления этого- оо, func, template. Вот надо из n таблиц выбрать 100500 вариантов по условиям и жоинам, соответственно, пиши 100500 запросов с 50%+ повторяющегося кода, или занимайся склейкой вручную или через какой ibatis. Причем, шансов, что очередная добавленная в запрос таблица родит такой план, что мама не горюй приближается к 100%.

[metaclass.livejournal.com]

Уже вообще решили - генерация из DSL. Нормальных, не дотнетовское LINQ-рукожопие.

[denisioru.livejournal.com]

На LINQ можно сократить до users.First(p => p.User_ID=User_ID).Name

[stdray.livejournal.com]

ага, тут еще надо блок try-catch и еще один знак "="

[blackyblack.livejournal.com]

Уже выяснили же, что ничего такого нет в природе. И ребе обязался СУБД на хаскеле написать с блэкджеком и мэпредюсом.

[smalgin.livejournal.com]

Если найдете, поделитесь. Будет интересно сравнить ощущения.

[thesz.livejournal.com]

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

Товарищи примером показали, что это единственный выход: http://cs-www.cs.yale.edu/homes/dna/papers/calvin-sigmod12.pdf

(смогли добиться производительности рекордсменов TPC на железе, в тысячи раз более дешёвом)