> всё-таки в сторону чтения документации прежде всего.Ну вот не попадалось прикольных примеров для скулайта для быстрого старта. А плотно вштыривать - я не DBA и не готов на это столько сил сливать если оно решаемо иными методами.
> ты и ключи компилятора тоже не используешь? ну, тебе же не надо
> экспертом по ключам становиться, тебе софт собрать? или всё-таки «это другое»?
В идеале - да, удобнее всего было бы запустить компилер и чтобы это был максимально компактный и быстрый код, все и сразу. Но у конкретно меня сборка софта бывает очень разнообразной. У фирмвари которая должна в 16 кил флехи влезть "хоть там что" приоритеты одни, а -10% скорости vs O2 обидно, но болт с ним: мы или успеваем в ралтайм, или нет. И если я уже тошнился в 10% от грани, я про@$#%лся на совсем других уровнях. А у вон той мегасофтины с 7-метровым бинарем исполняемого где надо максимальный перфоманс на том что есть, любой ценой, таки сильно разные приоритеты в кодогенерации. И чем ближе компилер к тому идеалу тем он лучше так то. В этом плане LTO например ацкий win: может урезать чуть не треть бинаря, ничего не теряя.
> *любой* гибкий и сложный инструмент желательно настраивать под свои нужды,
...и ты кажется не понял что я хочу простой и тупой но быстрый движок бд, для случая когда мне надо немного этого :). При этом моему низкоуровневому мозгу сие как-то проще и приятнее.
> потому что вероятность того, что настройки по умолчанию заточены на «средние показатели
> в как можно более широкой области применений» близка к единице.
Я как бы допускаю что мои хотелки отличаются от среднестатистических. Но даже они имхо могут хотеть резвый инсерт миллиона записей в базу. А хотя-бы для импорта/конверсии чего-то уже существовавшего.
> у каждого своё понятие «клёвого».
У меня это что-нибудь маленькое, простое, быстрое, ядреное, не жрущее ресурсы и при этом делающее что-нибудь интересное и полезное.
> ну что значит «прикольные»-то?
Простые, маленькие, быстрые как п@нос. Ну как у lwan например - полстранички на си и вот у вас уже скоростной вебсерв, с кастомными хэндлерами, можно GOпникам мастеркласс на тему микросервисов показывать.
> ограничение скулита — 2^31 на одно значение в базе (будь то ключ, или блоб-валуй).
Вообще, вполне нормально так то по описанию. А ключом может быть произвольный блоб без заморочек с эспейпингом и проч? Это удобно например чтобы чейто ник в виде как есть юзать как "ключ" и единственный критерий сам ник, а что за кал они туда записали - да пофиг. Ну вот не хочу я эскейпить и фильтрить бобби таблесов.
> потому что API использует инты; 64-бит апи тоже есть, но его добавили — по
> меркам SQLite — не так давно.
Да я не собираюсь многогиговые блобы в базу пхать. Скорее всякие мессаги человеческого размера и тому подобное добро, от цать байтов до эн кб. С оговоркой что я - вообще совсем не text minded существо и у меня в байте 8 битов. Поэтому я хочу оперировать всем этим прозрачно без вебмакачьих причуд с эскейпингом и какой там еще "читаемостью". Вон тот умеет так и в ключе и в значении и по диску эффективен, запрос заканчивается за пару io операций.
> впрочем, я не думаю, что кто-то тестировал его на ключах такого
> размера, так что полагаю, что более реальная мера — это где-то
> мегабайт для ключа. для валуя без разницы, там есть file-like API
> к ним. да, нули внутри этого никто не запрещает, и SQLite
> не поперхнётся.
А еще я не люблю оверинженерию. Не надо мне никаких file like api, если мне будет надо это, я таки умею файловой системой пользоваться. А делать что-то типа doc-файлов в мои планы не входит.
Ну то-есть если б у скулайта был вот реально лайт, где есть мини-версия с key-value двигуном отдельно от всяких файловых апи и скуля, я бы вероятно с ним познакомился сильно плотнее. А когда мне еще кучу мусора прут, мне оно не надо. Это только делает либ жирнее, медленнее, и уменьшает мое желание видеть это в depends.
> что и юзеры, которые хотят, чтобы им дали кнопку «сделай хорошо!»?
Конечно. И как-то так люди и работают :). Можно меня и обиднее пнуть, показав питонистов. Даже все так будет, НО есть нюансы: их код обычно медленный, кривой, с периодом полураспада год, падающий без обработки ошибок на каждый пук - и в конечном итоге я знаю что разработка софта все же комплексное мероприятие если хочется те соотношения как-то поприятнее.
> ровно как и остальные хранилища. отвратительный токийский кабинет использует
> тупую хэш-таблицу, размер которой я должен задавать при создании базы,
Токийский кабинет дает выбор между хэштаблицей и б-деревом и я совершенно ок с этой тупизной, будучи в состоянии выбрать параметры и тип осмысленно, там даже RTFMимть особо не надо ибо это азы CS, не зная которые считать себя прогером может только наглый веьманки. Зато небольшая либа, относительно простое апи, минимум лимитов, которые просто держать в голове. А не огромный монстр с автоматической задовытиралкой для тупиц там где мне хотелось "немного базы". Не, скуля не хотелось - я не dba и не мегаархитект баз данных, это не мое. Совсем.
> и автоматом ресайзить её не умеет.
Мне в многих моих случаях это ок.
> а если я количества записей заранее не знаю?
B-деревьям IIRC похрен. Да, там иные соотношения, O(1) vs O(log(N)). Но оно вроде и у скулайта вылезает, что они, волшебники? Или там какой-то нии...цца прорыв в CS случился заслуживающий внимания?
> ну, и будет там или куча неэффективной пустоты с page miss,
У меня разные кейсы, включая и системы с лимитированой RAM так что я на page cache и прочие огромные кеши могу и не хотеть ориентироваться.
> или оно выродится в блуждание по связаным спискам, с теми же page miss. (да, я его читал.)
Page miss вот так по максимуму беспокоит .. не всех и не всегда.
> чего?
Ну там insert и retrieve произвольного блоба-ключа и значения с минимумом допущений. Ну, кроме размера.
> обычно такое говорят люди, которые не умеют применять SQL.
А я и не хочу это уметь. Мне может хотеться "немного базы" но - именно немного. А вот всяких эскейпингов-экранирований, мега запросов и прочее - ну, это не ко мне.
> в 99% случаев в их коде наблюдается какой-нибудь кейвалуй, на котором они
> пытаются сэмулировать то, что SQL умеет из коробки, и получается у них всегда
> откровенно хуже.
Зато их не посетит боби тэйблс например. А если от него эффективно позатыкать все, начинается шоу, то какие-нибудь лимиты на буквы в никах, то экранирование с которым вечно лажа выходит. Усвой плиз, у меня байты 8-битные и я не хочу пытаться упихивать все как текст.
Ну например, у юзера токса уникальнй глобальный ID это 32 байта ключа. Технически это u8[32].
С этим бывают фееричные приколы. Скажем был мускул, я хотел в скулайт попробовать перегнать. База тривиальная но заполнена реальными юзерами. Агаблин, мускуль экспортирует свой чудный текст.. а дальше скуль то типа скуль, но здесь вам не тут - после тупняков полдня испорт таки завалился. Да, юзеры ввели очень странный булшит, и где-то на i++'ной записи оно сломалось, когда мнение мускула и скулайта об эскейпинге чего-то хитрого не совпали. Нюанс в том что я вообще совсем не хочу греть мой маленький мозг ПОДОБНЫМ БУЛШИТОМ. Совсем.
> я же не зря просил юзкейсы. у тебя задача, у которой это
> основной режим работы?
Нет конечно, НО возможны burst'ы активности и кроме того - а почему это должно работать хреново, собссно?
> потому что если это было начальное заселение базы — никто не мешал тебе отключить
> к чёрту весь ACID и остальные «тяжёлые» механизмы на время заселения.
Оно как бы да. Но все это напомнит о себе и при всплеске активности. И в принципе позволяет целенаправленно валить вон тот сервис вот этими запросами. В key-value я в принципе сильно меньше грею мозги такими вещами: там тормозить особо нечему. И если мне хотелось НЕМНОГО базы это не значит что я мечтал стать профессиональным DBA/девом умеющим в оптимизацию запросов и что там еще.
> откуда дровишки? потому что мой *практический* опыт такого не демонстрирует.
Да из их же мана насколько я помню. Но у них ман довольно здоровый и если я перепутал и источник другой - сорь.
> откуда я знаю, что для тебя «вау»?
См. выше. Ну да, сейчас это не модно. Но я люблю мелкий, шустрый, крутой, эффективный софт. Переклин на текстовом представлении в этом не помощник если что.
> будет. ему абсолютно всё равно.
Хм, может они что-то в движке переделали? Но раньше они не советовали за 20 гигз вылезать, что-то по части низкоуровневой механики как раз.
> не начинают. это раз. и два: а как у кейвалуев с выборкой типа: «хочу письма
> с тэгами abc и def, за период 'последний месяц', где в заголовке есть слово
> 'ЩАСТЕ', сортированые по дате, флажку 'important', и принадлежности к тредам»?
Так хотелки разные бывают, с вот такой я понимаю нафиг тебе скуль. На чистом key value оно конечно канительно, самому индексы строить на все и вся. Это решаемо, но изобретение вела зайжет далековато. Но у меня обычно хотелки сильно проще.
> мне вот это вот надо кодировать руками на каждый чих, или опять же руками пилить
> недо-sql, чтобы делать подобные выборки? а зачем, если у меня уже есть готовый
> SQL, который с подобными запросами справляется играючи?
Все так. Но у меня сильно более простые хотелки относительно баз.
> (да, пример из жизни; я часто создаю подобные «виртуальные каталоги» по запросам.
Оно как бы забавно но не думаю что мне сильно надо что-то такое.
> это всё ещё не тормозит.)
Ну как бы "не тормозит" без инфо по юзежу ресурсов мне ничего не говорит. Так то даже тяжелые и тормозные операции "не тормозят" если они где-то в фоне, но...
> однажды я понял, что хвалёные кейвалуи — это просто такие унылые хэш-таблички,
> и любую логику поверх них надо делать руками,
Спасибо кэп. Только про b-деревья еще забыл. Да, совершенно никакой черной магии. И я хочу вот что-то такое, когда мне надо НЕМНОГО базы с простой, тривиальной схемой данных.
> после чего преимущества кейвалуев резко уходят в никуда.
Кроме того что с ними не придется "ну ты ручками отключи ACID" - и вообще RTFMай в оптимизацию запросов дескать. Ух, а в мои планы точно входило стать профессиональным DBA чтобы столько RTFMать? А может я хотел простого чатбота например накодить, с тупой как дрова "схемой хранения"? Или там вебфигню тривиальную где база настройки по юзерам помнит, с идентификатором юзера который везде напихан и "primary key" по любому, а остальное в value прекрасно ложится и больше мне там ничего и не надо. А вот оптимизить запрос на скорость мне совсем не хочется.
> и что большинство моих требований отлично умеет SQL, и руками ничего писать
> не надо. и я стал просветлённый. хотя SQL пришлось учить, конечно.
Ну, мне вон те кейсы просто ни к чему. Я не пишу почтарь с поиском по 20 критериев за присест и виртуальными вью.
> ну и отлично. если бы ты изволил почитать документацию по SQLite, ты
> бы с удивлением обнаружил…
Да, она здоровенная и всю ее я ессно не читал. И фич в нем архидофига. Если мне надо вбить гвоздь, я хочу молоток. А пригнать мне компрессор и супермолот позволяющий загвоздить все вокруг - избыточно. Чтение инструкции как его запускать займет больше времени чем взять обычный простой молоток и забить гвоздь. Да, в молотке нет совсем никакой магии. Это простой инструмент для решения простых задач. Те кто планирует застроить целый квартал найдут более эффективный инструмент и чтение мана на его использование окупится.
> это типа я намекаю, что база не игрушечно-тестовая. а что значит «число
> записей», и что это за метрика — я не очень понимаю.
Ну то и значит.
> прикольных удобных штучек, и всё это совершенно бессмысленно считать тупым сложением
> (потому что при некоторых подсчётах может получиться вообще +inf).
Так я и не утверждал что скуль для этого чем-то плох. Мне просто столько не надою.
> я не зря упомянул, что каждый коннект активно работает с базой.
А все равно без данных профайлинга и знания конфиги мало что говорит.
>> Да даже просто bulk insert записей в солидном объеме мне хтонически не понравился.
> см. выше про это.
Ну да, ну да, я должен разучивать оптимизационные трюки даже для того чтобы просто базу сделать. Круто, всю жизнь мечтал почитать процедуру запуска навернутого компрессора при желании забить гвоздь.
