>> всё-таки в сторону чтения документации прежде всего.
> Ну вот не попадалось прикольных примеров для скулайта для быстрого старта.ну, то есть, сайт скулита ты не читаешь принципиально, я так понимаю. особенно старательно избегаешь раздел с документацией.
>> ты и ключи компилятора тоже не используешь?
…skip…
ну, то есть, задрачивать компилятор не впадлу. а сделать то же самое с другим инструментом — всё, западло, остальное пусть само как-нибудь. я этого не понимат.
>> *любой* гибкий и сложный инструмент желательно настраивать под свои нужды,
> ...и ты кажется не понял что я хочу простой и тупой но
> быстрый движок бд, для случая когда мне надо немного этого :).
я понял, что ты путаешь тупые хэш-таблички, и базы данных. это две СОВЕРШЕННО разные вещи.
> При этом моему низкоуровневому мозгу сие как-то проще и приятнее.
но пишешь ты в основном отчего-то на сях, я думаю, а не на асме. это я к тому, что кейвалуй — это как раз асм для бд.
>> потому что вероятность того, что настройки по умолчанию заточены на «средние показатели
>> в как можно более широкой области применений» близка к единице.
> Я как бы допускаю что мои хотелки отличаются от среднестатистических.
при чём тут это? они у всех разные. поэтому дефолтом идёт настройка: «среднехреново для всех». чего иногда хватает, а иногда нет.
> Но даже
> они имхо могут хотеть резвый инсерт миллиона записей в базу.
если это твой обычный юзкейс, и ты при этом используешь кейвалуй — то я очень рад, что не видел такого софта. потому что я очень легко пугаюсь, а это ядерный ужас — дальше всё только хуже. а если нет, то я всё ещё не понимаю нужды в гипероптимизации операции, которая нужна раз в год на большой праздник.
>> у каждого своё понятие «клёвого».
> У меня это что-нибудь маленькое, простое, быстрое, ядреное, не жрущее ресурсы и
> при этом делающее что-нибудь интересное и полезное.
это всё ещё ничего не описывает, увы. особенно в пунктах «интересное и полезное», которые у всех разные.
>> ну что значит «прикольные»-то?
> Простые, маленькие, быстрые как п@нос. Ну как у lwan например - полстранички
> на си и вот у вас уже скоростной вебсерв, с кастомными
> хэндлерами, можно GOпникам мастеркласс на тему микросервисов показывать.
извини, но это же ужасная оверинжинирнутая дрянь. до нормального «большого» оно не дотягивает, а для «на коленке» слишком перенаворочено.
>> ограничение скулита — 2^31 на одно значение в базе (будь то ключ, или блоб-валуй).
> Вообще, вполне нормально так то по описанию. А ключом может быть произвольный
> блоб без заморочек с эспейпингом и проч?
естественно.
> С оговоркой что я - вообще совсем не text minded
> существо и у меня в байте 8 битов. Поэтому я хочу
> оперировать всем этим прозрачно без вебмакачьих причуд с эскейпингом и какой
> там еще "читаемостью".
оперируй на здоровье.
> Вон тот умеет так и в ключе и
> в значении и по диску эффективен, запрос заканчивается за пару io
> операций.
шо, каждый раз пара i/o? отвратительно, никогда не используй такой ужас. ;-)
> А еще я не люблю оверинженерию. Не надо мне никаких file like
> api, если мне будет надо это, я таки умею файловой системой
> пользоваться. А делать что-то типа doc-файлов в мои планы не входит.
не надо — не используй, бинди/читай просто кусок памяти, нет проблем.
> Ну то-есть если б у скулайта был вот реально лайт
оно есть. называется SQLite.
> мини-версия с key-value двигуном отдельно от всяких файловых апи и скуля,
> я бы вероятно с ним познакомился сильно плотнее.
самое смешное, что такое тоже есть, но ты опять не читал документацию. проект SQLite4 был закрыт, как неудачный, но его хранилище доступно отдельно, и как библиотека, и как модуль для SQLite.
> А когда мне еще кучу мусора прут, мне оно не надо.
тебе дают один c-файл, и один h-файл. которые можно тупо скопипастить себе в дерево исходников и радоваться. так, например, делает фоссил.
>> ровно как и остальные хранилища. отвратительный токийский кабинет использует
>> тупую хэш-таблицу, размер которой я должен задавать при создании базы,
> Токийский кабинет дает выбор между хэштаблицей и б-деревом
и поэтому я должен заранее угадывать или количество ключей, или размер ключа. а если вдруг я это захочу поменять… ой, нет, уже не хочу.
> будучи в состоянии выбрать параметры и тип осмысленно,
> там даже RTFMимть особо не надо ибо это азы CS, не
> зная которые считать себя прогером может только наглый веьманки.
вообще-то любой инженер-практик тебе скажет, что выбрать заранее эти параметры осмысленно невозможно, вероятность ошибки 99.(9)%.
> Зато небольшая
> либа, относительно простое апи, минимум лимитов, которые просто держать в голове.
два мегабайта кода у токийского кабинета, полная невозможность использовать это как полноценную бд. восень мегабайт кода у SQLite, позноценная бд. ни то, ни другое ты (как и я) читать не будем. у SQLite при этом есть официальная амальгама, у кабинета нет. а, и ещё SQLite живой, а кабинет давно мумифицирован.
> А не огромный монстр с автоматической задовытиралкой для тупиц там где
> мне хотелось "немного базы". Не, скуля не хотелось - я не
> dba и не мегаархитект баз данных, это не мое. Совсем.
так ты и не пробовал, ты просто сразу, не разбираясь, решил, что НИНАДА. довольно неразумно, не находишь?
>> а если я количества записей заранее не знаю?
> B-деревьям IIRC похрен.
зато там фиксированый размер ключей.
>> чего?
> Ну там insert и retrieve произвольного блоба-ключа и значения с минимумом допущений.
> Ну, кроме размера.
на здоровье. SQLite вообще не занимается конвертацией чего-либо, если ты его явно не попросишь.
>> обычно такое говорят люди, которые не умеют применять SQL.
> А я и не хочу это уметь.
что опять-таки неразумно.
> Мне может хотеться "немного базы"
> но - именно немного. А вот всяких эскейпингов-экранирований, мега запросов и
> прочее - ну, это не ко мне.
я не знаю, откуда у тебя постоянно вылазят эти «эскейпинги-экранирования». попробуй разобраться с тем же SQLite не по руководствам для веб-макак, а по нормальной документации от авторов. есть мнение, что ты будешь приятно удивлён.
>> в 99% случаев в их коде наблюдается какой-нибудь кейвалуй, на котором они
>> пытаются сэмулировать то, что SQL умеет из коробки, и получается у них всегда
>> откровенно хуже.
> Зато их не посетит боби тэйблс например. А если от него эффективно
> позатыкать все, начинается шоу, то какие-нибудь лимиты на буквы в никах,
> то экранирование с которым вечно лажа выходит. Усвой плиз, у меня
> байты 8-битные и я не хочу пытаться упихивать все как текст.
см. выше.
> Ну например, у юзера токса уникальнй глобальный ID это 32 байта ключа.
> Технически это u8[32].
не вижу проблемы. храню в базе всякое, включая бинарные иды. всё работает. что такое это ваше «экранирование» — не знаю, и знать не хочу.
> С этим бывают фееричные приколы. Скажем был мускул, я хотел в скулайт
> попробовать перегнать. База тривиальная но заполнена реальными юзерами. Агаблин, мускуль
> экспортирует свой чудный текст.. а дальше скуль то типа скуль, но
> здесь вам не тут - после тупняков полдня испорт таки завалился.
извини, но ты сейчас очень круто сравнил два инструмента с *совершенно* разной областью применения. SQLite shell — это отладочный инструмент, а не фронтэнд. потому что SQLite предназначена для использования прямиком из кода, через её API.
>> я же не зря просил юзкейсы. у тебя задача, у которой это
>> основной режим работы?
> Нет конечно, НО возможны burst'ы активности и кроме того - а почему
> это должно работать хреново, собссно?
потому что это разные паттерны работы с данными. которые требуют разных подходов. в частности, SQLite из коробки настроен так, чтобы прозрачно и без дополнительных телодвижений поддерживать работу с одной базой одновременно из кучи приложений — поэтому он базу защищает. если тебе это не надо — это всё можно отключить, и оно будет сильно быстрее.
>> потому что если это было начальное заселение базы — никто не мешал тебе отключить
>> к чёрту весь ACID и остальные «тяжёлые» механизмы на время заселения.
> Оно как бы да. Но все это напомнит о себе и при
> всплеске активности.
а подумать ДО того, как писать код — не?
> В key-value я в принципе сильно меньше грею
> мозги такими вещами: там тормозить особо нечему.
охлол.
> И если мне хотелось
> НЕМНОГО базы это не значит что я мечтал стать профессиональным DBA/девом
> умеющим в оптимизацию запросов и что там еще.
«не хочу учиться, а хочу жениться!» ;-) в подавляющем большинстве случаев для написания нормального запроса достаточно рабочего мозга и опыта функционального программирования. потому что query planner'ы довольно умные (даже в SQLite), и средней паршивости запрос вполне приемлемо разрулят. в глубокий оптимайз обычно надо если ты хочешь от базы СТРАННОГО. например, получить кучу данных со связями одним запросом, а не ходить в базу за отдельными кусками (и это имеет смысл, потому что часто так быстрее; в кейвалуе у тебя просто нет никакого выбора в этом случае).
>> будет. ему абсолютно всё равно.
> Хм, может они что-то в движке переделали? Но раньше они не советовали
> за 20 гигз вылезать, что-то по части низкоуровневой механики как раз.
они и сейчас не советуют, потому что это не совсем область применения SQLite, и скорее всего, если у тебя базы таких размеров, и ты используешь SQLite, а не что-то серьёзней, то ты где-то сильно налажал. что не мешает пиплу спокоино ворочать скулитом базы далеко за 40 гигов, и оно вполне хорошо работает.
>> это всё ещё не тормозит.)
> Ну как бы "не тормозит" без инфо по юзежу ресурсов мне ничего
> не говорит. Так то даже тяжелые и тормозные операции "не тормозят"
> если они где-то в фоне, но...
я не люблю потоки без нужды. «не тормозит» — значит именно то, что оно при использовании не тормозит безо всяких фоновых обработок. то есть, время отклика софта в среднем не выше 16 мсек. да, я привык мерять в FPS, и предпочитаю, чтобы 60. ;-)
> И я хочу вот что-то такое, когда мне надо НЕМНОГО базы
> с простой, тривиальной схемой данных.
проблема в том, что кейвалуй — ни разу не база. бд позволяет запрашивать, сортировать и фильтровать данные по разным критериям, а не тупо по одному ключу.
>> после чего преимущества кейвалуев резко уходят в никуда.
> Кроме того что с ними не придется "ну ты ручками отключи ACID"
да. потому что обычно никакого акцида тупо не дают. поэтому если вдруг я его захочу включить… ну, ой. предпочитаю иметь возможность его выключить, а не не иметь возможности его включить.
> и вообще RTFMай в оптимизацию запросов дескать.
ты опять откуда-то взял странное. я тебе говорю почитать официальную документацию по API.
> может я хотел простого чатбота например накодить, с тупой как дрова
> "схемой хранения"?
с этим скулит справится даже без тюнинга. с огромным запасом.
>> и что большинство моих требований отлично умеет SQL, и руками ничего писать
>> не надо. и я стал просветлённый. хотя SQL пришлось учить, конечно.
> Ну, мне вон те кейсы просто ни к чему. Я не пишу
> почтарь с поиском по 20 критериев за присест и виртуальными вью.
а это как с фоссилом: ты не умеешь в SQL, но уверен, что оно тебе не надо. скажу тебе по секрету, что мне оно тоже было не надо, а SQLite была жирной перегруженой бесполезной ерундой — ровно до того момента, как я осознал, что даже не попытался сначала разобраться в инструменте, и только потом его браковать. и разобрался. и вдруг случилось чудо: я повыкидывал остальные кейвалуи, а SQL мне стал прельстив.
> Да, она здоровенная и всю ее я ессно не читал.
именно поэтому на родном сайте есть не только API reference.
> И фич в нем архидофига.
и что самое прикольное: никто тебя не заставляет обязательно использовать каждую из них!
> Чтение инструкции как его запускать займет больше времени чем взять
> обычный простой молоток и забить гвоздь.
но ты ведь даже не пробовал читать, ты просто решил, что многабукав.
>> это типа я намекаю, что база не игрушечно-тестовая. а что значит «число
>> записей», и что это за метрика — я не очень понимаю.
> Ну то и значит.
это ничего не значит в контексте *базы* *данных*. эта метрика имеет смысл для какой-нибудь хэш-таблички.
>> я не зря упомянул, что каждый коннект активно работает с базой.
> А все равно без данных профайлинга и знания конфиги мало что говорит.
ну так ты ж тоже этого не привёл, так что мы тут один фиг меряемся воображаемыми розовыми слонами. в частности я пытаюсь тебе впарить клёвого симпатичного слона с четырьмя ногами и хоботом вместо твоего одногого и с хвостом на лбу.
>>> Да даже просто bulk insert записей в солидном объеме мне хтонически не понравился.
>> см. выше про это.
> Ну да, ну да, я должен разучивать оптимизационные трюки даже для того
> чтобы просто базу сделать. Круто, всю жизнь мечтал почитать процедуру запуска
> навернутого компрессора при желании забить гвоздь.
нет, тебе надо просто почитать документацию. это совсем небольно. в ней, например, можно найти рекомендации по тому, как делать bulk insert, и какие бывают подводные камни.
