> Прелесть кв не в блобятине - на блобятину можно и скуль заточить Прелесть - в том что k/v
1) Затачивать не надо - ему индиффирентно чего жрать с самого начала в большинстве реализаций.
2) Оверхеда на это ноль.
3) Сам по себе он быстрый.
4) Иньектить во многие реализации вообще совсем не получится.
5) Просто для понимания програмером. Если приходится вычитывать 1005000 записей - програмер быстро замечает неоптимальность. А в скуле он даже и не узнает о том что его select * from немеряная_таблица - это плохо. Потому что на его тестовом серванте с 10 записей и так катило. А вот когда это выкатят в продакшн - тут то и начнется конкретное ололо, при том не сразу, что особенно доставляет :)
> (уже ж говорил - prepared statement, и никаких проблем). Прелесть в
> сравнительно шустром доступе к данным по ключу.
Ну спасибо, Капитан. Это не просто "сравнительно шустрый" доступ. Это близко к наиболее быстрому с теоретической точки зрения для данной технологии стоража. Потому что это лобовая команда сторажу "дай вот это". Для b-дерева или хэш-таблицы это довольно быстрая и дешевая операция. Тот же токийский кабинет напрмер гарантирыет всего 2 запроса к диску на успех и 1 запрос к диску на неуспех.
И, кстати, к вопросу о размере и гектарах. В б-деревьях скорость относительно числа записей падает логарифмически, т.е. довольно медленно. В хэш-таблицах она вообще в среднем по больнице константа. По поводу чего сам по себе k/v или нечто подобное можно с чистой совестью юзать под очень масштабные применения. Майкрософтушка вон юзает какой-то относительно низкоуровневый ESE для AD о десятках миллионов объектов и Exchange с гигазами почты - и никакого вам скуля.
И если уж на то пошло - безбашенно накормить скуль запросом который где-то там внутри проелозит весь диск и все 100 000 000 записей - фигня вопрос. Достаточно безбашенено написать запрос и вытаскивание единственной записи будет занимать полчаса. В случае k/v сие делать неудобно, чисто технически. Програмер очень быстро заметит что его алгоритмика оставляет желать, в отличие от скуля, где это будет зарыто под слоем абстракций, которые хорошо понимает далеко не каждый кто использует SQL.
> С другой стороны, скуль и KV тихонько сливаются в экстазе - вон, NDB или TokuDB
> (TokuMX, если хотите NoSQL), и разница между ними становится в один парсер.
А вот это в принципе логично, т.к. после парсера запрос по логике вещей можно скормить относительно простому и низкоуровневому сторажу, оперирующему куда более простыми вызовами. А дальше по мере надобности выбирать как лучше. Если видится вариант сразу представить все запросы в нативном понимании стоража, оптимально - значит так. А если такой вариант с наскока не придумался и/или ожидается усложнение абстракций - логично SQL заюзать.
> Да и для InnoDB NoSQL access уже запилили. С inmemory тот же Inno/Toku
> не сравнить, конечно, но мы и не о inmemory говорим.
Как бы это сказать? Хороший key-value на быстром носителе типа SSD или тем более в RAM (cache hit или просто in-memory база) покажет именно эти самые свойства. Собственно in-memory и делают по каким-то таким технологиям, вся разница лишь в том что они обычно не имеют дело с диском напрямую и по этому поводу возможны некоторые послабления и упрощения иногда.
> А NDB неплохо так масштабируется, но он явно не эмбеддед :)
Ну если капитанить то у САБЖА кстати тоже есть SQLный фронтэнд, так что он и так и сяк умеет, правда тех кто юзал бы его через скуль я не видел, но при желании это можно :).
И если уж на то пошло, самому по себе key/value нет никаких причин не масштабироваться. Вон файловые системы до терабайтов масштабируются спокойно. Да и многие иные смогут. А чего б им? Лежащая в основе технология не чувствительна или мало чувствительна к размеру стоража сама по себе. Это програмер и его логика может облажать уже. Ну так оно и в SQL с нубами и select * тоже облажается. При том написать select * явно проще чем написать код явно читающий 100 000 записей, так что на SQL тормозные запросы как раз правило а не исключение :)
> Имхо будущее за гибридными движками хранилищ, к которым можно обратиться и так
> и сяк, в зависимости от потребности.
Ну а вот это было бы логично - разделить на "парсер" и "движок". При этом можно было бы менять что парсер на какой-то кастомный, проблемо-ориентированный при нужде, так и движок, на тот который лучше подходит по свойствам. Ну так, в идеале.
