>> эм… я предполагал, что раз ты говоришь про тормоза — то ты
>> сравнивал с чем-то. «светится в профайлинге» — это, извини, не критерий.
> Для меня это как раз таки критерий. О его идеальности можно заспорить,
> но все же, это позволяет осмысленно наседать на проблемы перфоманса -
> понимая во что уперлось и в какую сторону копать.всё-таки в сторону чтения документации прежде всего.
>> особенно с учётом того, что скулит можно довольно гибко настраивать под разные применения,
> Между нами, я очень не хочу крутить кучу tunables и становиться чем-то
> типа DBA
ты и ключи компилятора тоже не используешь? ну, тебе же не надо экспертом по ключам становиться, тебе софт собрать? или всё-таки «это другое»? *любой* гибкий и сложный инструмент желательно настраивать под свои нужды, потому что вероятность того, что настройки по умолчанию заточены на «средние показатели в как можно более широкой области применений» близка к единице.
> При этом очень кстати если первая попытка знакомства
> покажет что-то клевое, а не унылый булшит.
у каждого своё понятие «клёвого».
> И таки я не против накодить какоинить бенч ради лулзов - есть
> прикольные примеры юзежа скулайта как именно key-value?
ну что значит «прикольные»-то?
> Желательно с произвольным ключом
> и значением, токийский кабинет приколен тем что жрет любое бинарное нечто
> как таковые с минимальными constraints на это все.
ограничение скулита — 2^31 на одно значение в базе (будь то ключ, или блоб-валуй). потому что API использует инты; 64-бит апи тоже есть, но его добавили — по меркам SQLite — не так давно. впрочем, я не думаю, что кто-то тестировал его на ключах такого размера, так что полагаю, что более реальная мера — это где-то мегабайт для ключа. для валуя без разницы, там есть file-like API к ним. да, нули внутри этого никто не запрещает, и SQLite не поперхнётся.
>> но почти никто этого делать не желает, потому что в документации многабукав.
> В конечном итоге я решить задачу хочу, а чтение манов лишь некое
> техническое зло...
ты же понимаешь, что этой фразой определяешь себя в ту же категорию, что и юзеры, которые хотят, чтобы им дали кнопку «сделай хорошо!»?
> Просто на нижнем уровне насколько я помню движок скулайта вообще никаких интересных
> свойств не показывал.
ровно как и остальные хранилища. отвратительный токийский кабинет использует тупую хэш-таблицу, размер которой я должен задавать при создании базы, и автоматом ресайзить её не умеет. а если я количества записей заранее не знаю? ну, и будет там или куча неэффективной пустоты с page miss, или оно выродится в блуждание по связаным спискам, с теми же page miss. (да, я его читал.)
> Я что-то пропустил? Ну, дай какие-нибудь интересные примеры
> чего-то низкоуровневого и быстрого на нем?
чего?
> Скуль мне не интересен как категория.
обычно такое говорят люди, которые не умеют применять SQL. в 99% случаев в их коде наблюдается какой-нибудь кейвалуй, на котором они пытаются сэмулировать то, что SQL умеет из коробки, и получается у них всегда откровенно хуже.
> Ну, я 100К и 1М записей добавлял в скулайт базы.
я же не зря просил юзкейсы. у тебя задача, у которой это основной режим работы? потому что если это было начальное заселение базы — никто не мешал тебе отключить к чёрту весь ACID и остальные «тяжёлые» механизмы на время заселения.
> У скулитовского бэка насколько я помню есть проблемы с масштабированием (файлы более
> 20 гигз ему вообще категорически противопоказаны)
откуда дровишки? потому что мой *практический* опыт такого не демонстрирует.
> и это, там есть что-то глядя на что я бы сказал вау?
откуда я знаю, что для тебя «вау»?
>> мой почтовик, например, вообще ничего не кэширует, а просто на каждую перерисовку
>> экрана ходит в базу.
> А будет ли он адекватно себя вести если у меня например почтовая
> база под 80 Гб с сотнями тысяч сообщений?
будет. ему абсолютно всё равно.
> Многим key-value сам
> по себе размер или число item'ов относительно пофиг, а у скулайта
> после ~20 гигз начинают тупить внутренние операции их двигуна с страницами
> и деревьями как я понял.
не начинают. это раз. и два: а как у кейвалуев с выборкой типа: «хочу письма с тэгами abc и def, за период 'последний месяц', где в заголовке есть слово 'ЩАСТЕ', сортированые по дате, флажку 'important', и принадлежности к тредам»? мне вот это вот надо кодировать руками на каждый чих, или опять же руками пилить недо-sql, чтобы делать подобные выборки? а зачем, если у меня уже есть готовый SQL, который с подобными запросами справляется играючи?
(да, пример из жизни; я часто создаю подобные «виртуальные каталоги» по запросам. это всё ещё не тормозит.)
> Странный ты тип, рисовать курсор самому битмапом но при этом скулем ворочать...
однажды я понял, что хвалёные кейвалуи — это просто такие унылые хэш-таблички, и любую логику поверх них надо делать руками, после чего преимущества кейвалуев резко уходят в никуда. и что большинство моих требований отлично умеет SQL, и руками ничего писать не надо. и я стал просветлённый. хотя SQL пришлось учить, конечно.
> Лично мне нравится когда запросы к бд прямые, быстрые, и без ограничений
> на то что в ключе и значении, как бинарные данные, без
> преобразований.
ну и отлично. если бы ты изволил почитать документацию по SQLite, ты бы с удивлением обнаружил…
>> да, на базе под гигабайт.
> Это, типа, много? И каком числе записей в базе?
это типа я намекаю, что база не игрушечно-тестовая. а что значит «число записей», и что это за метрика — я не очень понимаю. это база данных, а не кейвалуй, она умеет более чем в одну таблицу. у меня там хранилище, словари, view-ы, и ещё много прикольных удобных штучек, и всё это совершенно бессмысленно считать тупым сложением (потому что при некоторых подсчётах может получиться вообще +inf).
>> а ботоотсекалка, которая сидит перед моим веб-сервером, спокоино в состоянии
>> обработать десятки тысяч коннектов с секунду — а она тоже активно ходит в базу,
> Оно как бы здорово - но опять же без хотя-бы данных профайлинга
> не говорит мне чуть менее чем ничего. Ибо сами по себе
> десятки тыщ конектов в секунду на современнном железе не есть что-то
> этакое.
я не зря упомянул, что каждый коннект активно работает с базой.
>> каждый раз читает оттуда кучу всего, и пишет туда логи на каждый чих почти. так что
>> я слабо себе представляю, что у тебя за особенные задачи такие,
>> где скулит тормозит — и мне неиронично интересно.
> Да даже просто bulk insert записей в солидном объеме мне хтонически не
> понравился.
см. выше про это.
