> эм… я предполагал, что раз ты говоришь про тормоза — то ты
> сравнивал с чем-то. «светится в профайлинге» — это, извини, не критерий.Для меня это как раз таки критерий. О его идеальности можно заспорить, но все же, это позволяет осмысленно наседать на проблемы перфоманса - понимая во что уперлось и в какую сторону копать.
> особенно с учётом того, что скулит можно довольно гибко настраивать под разные применения,
Между нами, я очень не хочу крутить кучу tunables и становиться чем-то типа DBA - я хочу решить те или иные задачи и DB там лишь одно из звеньев. Чем меньше оно внимания к себе требует, при более забористом перфомансе и мизерном жраче ресурсов, тем я довольнее жизнью. При этом очень кстати если первая попытка знакомства покажет что-то клевое, а не унылый булшит.
И таки я не против накодить какойнить бенч ради лулзов - есть прикольные примеры юзежа скулайта как именно key-value? Желательно с произвольным ключом и значением, токийский кабинет приколен тем что жрет любое бинарное нечто как таковые с минимальными constraints на это все. Так что бобби тэйблс может любой ник брать а мне ничего не будет за юзеж оного как key, например. Мне нравятся такие апи.
> но почти никто этого делать не желает, потому что в документации многабукав.
В конечном итоге я решить задачу хочу, а чтение манов лишь некое техническое зло...
Просто на нижнем уровне насколько я помню движок скулайта вообще никаких интересных свойств не показывал. Я что-то пропустил? Ну, дай какие-нибудь интересные примеры чего-то низкоуровневого и быстрого на нем? Скуль мне не интересен как категория.
> ну вот мне и интересно, что это было, что именно тормозило, и
> пытался ли ты читать документацию, чтобы выставить правильные прагмы, например.
Ну, я 100К и 1М записей добавлял в скулайт базы. Как минимум с сиквелем время получалось никакое даже при попытке группировки в 1 или несколько транзакций, даже при самой тривиальной структуре таблицы. При том попытки группировки еще и куча грабель. А если входные данные еще и абы что - это вообще задник.
> p.s.: я, к примеру, местами даже доморощеные хэш-таблички в некоторых сишных проектах
> повыкидывал, потому что скулит справляется достаточно быстро.
У скулитовского бэка насколько я помню есть проблемы с масштабированием (файлы более 20 гигз ему вообще категорически противопоказаны) - и это, там есть что-то глядя на что я бы сказал вау? Допустим что SQL меня не интересует - а как key value он таки на первый взгляд нечто странное. Есть какие-то "эпичные" примеры как его в режиме key-value, без всякого скуля?
> мой почтовик, например, вообще ничего не кэширует, а просто на каждую перерисовку
> экрана ходит в базу.
А будет ли он адекватно себя вести если у меня например почтовая база под 80 Гб с сотнями тысяч сообщений? Многим key-value сам по себе размер или число item'ов относительно пофиг, а у скулайта после ~20 гигз начинают тупить внутренние операции их двигуна с страницами и деревьями как я понял.
> и то, что я забыл отключить полную перерисовку экрана при любом движении мыши
> я заметил очень не сразу, потому что не тормозит (а тормоза были бы видны,
> потому что я рисую мышиный курсор битмапом в виртуальный экран, а не использую аппаратный).
Странный ты тип, рисовать курсор самому битмапом но при этом скулем ворочать...
Лично мне нравится когда запросы к бд прямые, быстрые, и без ограничений на то что в ключе и значении, как бинарные данные, без преобразований.
> да, на базе под гигабайт.
Это, типа, много? И каком числе записей в базе?
> а ботоотсекалка, которая сидит перед моим веб-сервером, спокоино в состоянии
> обработать десятки тысяч коннектов с секунду — а она тоже активно ходит в базу,
Оно как бы здорово - но опять же без хотя-бы данных профайлинга не говорит мне чуть менее чем ничего. Ибо сами по себе десятки тыщ конектов в секунду на современнном железе не есть что-то этакое.
> каждый раз читает оттуда кучу всего, и пишет туда логи на каждый чих почти. так что
> я слабо себе представляю, что у тебя за особенные задачи такие,
> где скулит тормозит — и мне неиронично интересно.
Да даже просто bulk insert записей в солидном объеме мне хтонически не понравился. В том плане что вот это вот на key value имеет свойство быть сильно резвее. Да, конечно, можно порассуждать про фичи, гарантии и проч - но будем честны, я не люблю SQL и не намерен им пользоваться. А вот базы key-value иногда юзаю.