LINUX.ORG.RU

Key-value storage (?), с непредсказуемым key или document storage

 


0

0

Короче, ребзя, нужно мне создавать и классифицировать файлы по нескольким параметрам. Например, по толщине и зелёности. Сейчас я использую иерархическое хранение в файловой системе, вроде: "./толщина:XXXсм./зелёность:YYY%/".

Но становится ясно, что параметры могут добавляться в будущем и наращивать глубину иерархии не хочется. К тому же, есть подозрение, что скоро понадобятся параметры, скажем так, равнозначные. Текущие параметры всегда присутствуют, разница только в их значении. «Равнозначные» могут присутствовать или отсутствовать в любой комбинации. Не хочется придумывать, каким образом их упорядочивать и как вообще кодировать в имени пути.

Решил я, что мне нужна БД, которая бы брала набор параметров и возвращала мне что-нибудь, что можно использовать как путь. Похрену, что. UUID, например.

Из требований: легкость в освоении и настройке, т.к. записей там будет всего несколько сотен и нет смысла возиться с настройкой производительности; работа по сети.

Хочется в неком смысле «атомарности». В том, что если несколько клайентов обнаружат, что для данного ключа нет value и захотят добавить его, то чтобы это смог сделать только один, а остальные смогли корректно узнать об этом, т.е. получить добавленное одним из них значение.

Остальное выясним в процессе обсуждения.

★★★

Последнее исправление: utf8nowhere (всего исправлений: 2)

т.к. записей там будет всего несколько сотен

то индекс можно хранить в памяти, а данные хоть в рулонах таулетной бумаги монге, т.е. ничего менять не надобно

Deleted
()
Ответ на: комментарий от Deleted

а данные хоть в монге, т.е. ничего менять не надобно

Так сейчас никаких монг нет. Есть захардкоженные в софте шаблоны путей до файлов, куда подставляются значения параметров.

utf8nowhere ★★★
() автор топика
Ответ на: комментарий от utf8nowhere

ну или так, опятьже я не понял, если у тебя клиент-сервер-бд - то разруливать конкуррентность ты можешь на сервере, если несколько серверов, то да придется попотеть, либо блокировки, либо эвенты

и укажи какой максимальный размер одного value

Deleted
()
Ответ на: комментарий от Deleted

ну или так, опятьже я не понял, если у тебя клиент-сервер-бд - то разруливать конкуррентность ты можешь на сервере, если несколько серверов, то да придется попотеть, либо блокировки, либо эвенты

Понятия не имею, сколько у меня чего. Софтина хочет дать кому-то описание параметров и получить назад путь, куда сохранять файл. Таких софтин может быть несколько одновременно, как на локалхосте (эксплуатирую SMP), так и в сети.

и укажи какой максимальный размер одного value

что-нибудь, что можно использовать как путь

(JSON в качестве пути не предлагать.)

utf8nowhere ★★★
() автор топика

Почти под любые задачи смотреть есть смысл среди leveldb, sqlite, tarantool, redis, mysql/postgresql, mongodb. Все поднимаются с пол пинка.

Под твои объемы можно тупо в память все пихать как json и выбирать сканом. Соответственно, транзакционность не нужна, потому что атомарность и так есть.

А из-за того что ты хочешь много клиентов и персистанс, тебе простые базы не подойдут, потому что они однотредовые (типа, эмбеддед). Соответственно, нужен либо тупой сторадж с серверной обвязкой, либо полноценная база.

Трудно что-то конкретное с ходу назвать, не зная всех нюансов. Лучше сам посмотри из списка.

Vit ★★★★★
()
Ответ на: комментарий от utf8nowhere

с такими масштабами тебе sqlite хватит, но если сильно хочется то любую реляционную субд, зачем тебе kv если ты хочешь по нескольким критериям искать.

Deleted
()
Ответ на: комментарий от utf8nowhere

Софтина хочет дать кому-то описание параметров и получить назад путь, куда сохранять файл

Тут ты с базами не по адресу, КМК. Использовать ее ради химии с индексами для хранения единственного рандома - это какой-то дикий оверкил.

По-моему тебе нужна хеш-функция от набора параметров. Определись, что на ключ должно влиять, выпиши значения через запятую и посчитай sha1, например.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Черт я думал что ТС будет выборку по отдельному критерию делать, если нет то да тупо хеш и все.

Deleted
()
Ответ на: комментарий от Deleted

Эти «несколько критериев» могут расширяться. Например, вчера мы не различали по sd-positiveness, сегодня различаем. При этом вчерашние файлы мы дальше храним.

utf8nowhere ★★★
() автор топика
Ответ на: комментарий от Deleted

Он по-моему еще не смог до конца сформулировать что хочет. Конкуренси надо когда куча клиентов и работа с диском. С памятью этих проблем нет, т.к. задержка нулевая и просто глобальный лок на операцию ставится.

Vit ★★★★★
()
Ответ на: комментарий от Vit

дык после кипятильника он признался что у него куча какихто софтин, одна бд которую он хочет и диск с файлами

Deleted
()
Ответ на: комментарий от Vit

По-моему тебе нужна хеш-функция от набора параметров.

Не хочется придумывать, каким образом их упорядочивать и как вообще кодировать...

«{ толщина: 200см; зелёность: 100%; }» и «{ зелёность: 100%; толщина: 200см; }» будут иметь разный хеш, но я не хочу их различать.

utf8nowhere ★★★
() автор топика
Ответ на: комментарий от Deleted

Куча экземпляров одной и той же софтины запущены одновременно.

utf8nowhere ★★★
() автор топика
Ответ на: комментарий от utf8nowhere

Посмотри гугловский protobuf, на тему обратной совместимости структур.

База тебе не даст какой-то волшебной магии. Ты будешь точно так же долбиться с совместимостью, только на уровне конвертации таблиц и т.п. Определиться из каких полей надо генерить уникальный ключ - все равно придется.

Vit ★★★★★
()
Ответ на: комментарий от Deleted

хотя нет, както так:

tableFiles
id|filename
-------------
1   one
2   two

tableKinds
id|title
---------
1  color
2  weigth

tableFileKinds
fileId|kindId | value
---------------- 
1       1       green
1       2       2kg
0       1       red
Deleted
()
Ответ на: комментарий от utf8nowhere

«{ толщина: 200см; зелёность: 100%; }» и «{ зелёность: 100%; толщина: 200см; }» будут иметь разный хеш, но я не хочу их различать.

А по ключам («толщина», «зелёность») отсортировать никак?

theNamelessOne ★★★★★
()
Ответ на: комментарий от utf8nowhere

вон выше я тебе накидал из трех табличек (но irl надо чуть больше), наколдуй к аксесес или что там у тебя под рукой есть посочиняй запросы на выборку и все, очеивидно что можно в рантайме добавлять\удалять критерии и типы критериев любому файлу

Deleted
()
Ответ на: комментарий от utf8nowhere

Надо ж сортировать перед склейкой. Если только для уникальности - можно тупо по алфавиту.

Vit ★★★★★
()
Ответ на: комментарий от utf8nowhere

Как, но это уже относится к «думать, как упорядочить», а я бы хотел этого избежать.

Тут не надо думать, я уже сказал, что нужно сделать — отсортировать. Лексикографическая сортировка — это элементарная операция, которую может любой ЯП высокого уровня. А если твой ЯП её не умеет, то реализовывается она за 5 минут.

theNamelessOne ★★★★★
()

мне создавать и классифицировать файлы по нескольким параметрам.
что параметры могут добавляться в будущем и наращивать глубину иерархии
мне нужна БД, которая бы брала набор параметров и возвращала мне что-нибудь
записей там будет всего несколько сотен

На таком «гигантском» объеме - тупо MySQL. Где каждый признак - это колонка. Нужен новый признак - добавляем новую колонку.

Pinkbyte ★★★★★
()
Ответ на: комментарий от theNamelessOne

Да, у меня была такая идея ещё до создания треда. И пока в треде ничего лучшего не предложили.

utf8nowhere ★★★
() автор топика
Ответ на: комментарий от utf8nowhere

У них появится дефолтное значение нового поля. Которое либо ты задашь, либо оно будет NULL, что в терминах SQL означает его отсутствие

Pinkbyte ★★★★★
()
Ответ на: комментарий от utf8nowhere

Надо будет делать ALTER TABLE и указывать дефолтное значение. Но вообще всякий рандомный шлак по которому нет выборок можно в одно поле в виде JSON закатать.

Vit ★★★★★
()
Ответ на: комментарий от Pinkbyte

На таком «гигантском» объеме - тупо MySQL. Где каждый признак - это колонка.

Костыль какой. Лучше уж Postgres с полем типа hstore (и повесить на него unique index), у него ключи автоматически сортируются:

select 'c => d, a => b'::hstore = 'a => b, c => d'::hstore;
 ?column? 
----------
 t
(1 row)
theNamelessOne ★★★★★
()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

Ах, да. Проблема — нельзя делать запросы. В смысле, wildcard. Хотя, если сохранять в директорию оригинальный json-файл, то при «объёме» в несколько сотен директорий можно и проходиться по ним и просто читать json-файлы.

utf8nowhere ★★★
() автор топика
Ответ на: комментарий от utf8nowhere

Тогда Psql + hstore — то, что доктор прописал:

postgres=# create table adhoc_kv (
postgres(# key hstore not null,
postgres(# value text not null
postgres(# );
CREATE TABLE
postgres=# create unique index on adhoc_kv(key);
CREATE INDEX
postgres=# insert into adhoc_kv(key, value) VALUES ('a => b, c => d'::hstore, 'value 1'), ('a => b, x => y'::hstore, 'value 2');
INSERT 0 2
postgres=# -- look, ma, unique index!
postgres=# insert into adhoc_kv(key, value) VALUES ('c => d, a => b'::hstore, 'ignored value') on conflict(key) do nothing;
INSERT 0 0
postgres=# select * from adhoc_kv;
        key         |  value  
--------------------+---------
 "a"=>"b", "c"=>"d" | value 1
 "a"=>"b", "x"=>"y" | value 2
(2 rows)

postgres=# -- exact match
postgres=# select value from adhoc_kv where key = 'c => d, a => b'::hstore;
  value  
---------
 value 1
(1 row)

postgres=# -- "wildcard" search
postgres=# select value from adhoc_kv where key @> 'a => b'::hstore;
  value  
---------
 value 1
 value 2
(2 rows)
theNamelessOne ★★★★★
()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от utf8nowhere

Что кстати лучше. На большом кол-ве JSON записей Monga лучше справляется с поиском по индексированным полям (тестили на ~1.5 миллионах записей EAN 13 (которые штрихкоды) распиханных в документы). Разве что там есть ограничение на размер документа (ищи сам в гугле, сейчас не помню какое оно), если попытаешься вставить слишком большой док - кинет эксепшн.

Ну и там свои заморочки с транзакциями - покури гугл опять же. Мне в монге они были не нужны никогда, но какие-то косяки были с ними.

Norgat ★★★★★
()
Последнее исправление: Norgat (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.