YS
чтобы я оценил, за какое время данные вставятся, а то так можно запустить процесс до тепловой смерти вселенной и не знать об этом
А batches какого размера? И сколько всего записей?
Size: a a a
2021 January 28
ЯТ
Yaroslav Schekin
В смысле? Вон он, выше написан — что с ним не так-то? ;)
WHERE key = 'something' - это "something" будет ="username:<unknown_string>"
ЯТ
и нужно будет по части строки искать, что выливается в полный скан таблицы, b-tree тут не поможет
ЯТ
Yaroslav Schekin
А batches какого размера? И сколько всего записей?
Вставки по 100к элементов, всего 4 млрд пока. Каждая вставка ~20 секунд пока что
YS
WHERE key = 'something' - это "something" будет ="username:<unknown_string>"
Т.е. Вам нужен действительно поиск по части поля "ключ", или что?
Вы конкретный запрос можете показать, на всякий случай?
Вы конкретный запрос можете показать, на всякий случай?
ЯТ
Yaroslav Schekin
Т.е. Вам нужен действительно поиск по части поля "ключ", или что?
Вы конкретный запрос можете показать, на всякий случай?
Вы конкретный запрос можете показать, на всякий случай?
> если у меня в ключе будет храниться пара key-value
ЯТ
а если в значении будет value, то надо думать как обеспечить уникальность
ЯТ
ну т.е. тогда придётся включать в этой nosql БД функцию хранения дубликатов
YS
а если в значении будет value, то надо думать как обеспечить уникальность
Ещё раз, Вы делаете так:
1. Создаёте [аналог] уникального индекса по ("ключ" + "значение") — это уж должны уметь все KV.
2. Делаете префиксный поиск — это умеет любое b-tree.
Т.е. полный аналог того, что у Вас есть сейчас в PostgreSQL — у Вас PK(login, password), и
"SELECT * FROM leak_entries WHERE login = 'a_login';" его использует, так?
1. Создаёте [аналог] уникального индекса по ("ключ" + "значение") — это уж должны уметь все KV.
2. Делаете префиксный поиск — это умеет любое b-tree.
Т.е. полный аналог того, что у Вас есть сейчас в PostgreSQL — у Вас PK(login, password), и
"SELECT * FROM leak_entries WHERE login = 'a_login';" его использует, так?
ЯТ
Yaroslav Schekin
Ещё раз, Вы делаете так:
1. Создаёте [аналог] уникального индекса по ("ключ" + "значение") — это уж должны уметь все KV.
2. Делаете префиксный поиск — это умеет любое b-tree.
Т.е. полный аналог того, что у Вас есть сейчас в PostgreSQL — у Вас PK(login, password), и
"SELECT * FROM leak_entries WHERE login = 'a_login';" его использует, так?
1. Создаёте [аналог] уникального индекса по ("ключ" + "значение") — это уж должны уметь все KV.
2. Делаете префиксный поиск — это умеет любое b-tree.
Т.е. полный аналог того, что у Вас есть сейчас в PostgreSQL — у Вас PK(login, password), и
"SELECT * FROM leak_entries WHERE login = 'a_login';" его использует, так?
да
YS
Вставки по 100к элементов, всего 4 млрд пока. Каждая вставка ~20 секунд пока что
Хмм... при типичных размерах login, password и source (тут не уверен, что это) — это как-то уж очень медленно...
YS
Ну так и почему бы этому не работать?
ЯТ
Yaroslav Schekin
Ну так и почему бы этому не работать?
> Создаёте [аналог] уникального индекса по ("ключ" + "значение") — это уж должны уметь все KV
Я пока не нашёл такого. У всех поведение по дефолту - уникальный ключ, каждая следующая вставка перезапишет предыдущую. Дальше нужно рыть доки - можно ли включить хранение дубликатов и т.д.
Я пока не нашёл такого. У всех поведение по дефолту - уникальный ключ, каждая следующая вставка перезапишет предыдущую. Дальше нужно рыть доки - можно ли включить хранение дубликатов и т.д.
ЯТ
В основном такие БД заточены под хранение json в value - я так прикинул, что это будет то же самое, что в постгресе, только ещё хуже из-за постоянного парсинга жсон
YS
> Создаёте [аналог] уникального индекса по ("ключ" + "значение") — это уж должны уметь все KV
Я пока не нашёл такого. У всех поведение по дефолту - уникальный ключ, каждая следующая вставка перезапишет предыдущую. Дальше нужно рыть доки - можно ли включить хранение дубликатов и т.д.
Я пока не нашёл такого. У всех поведение по дефолту - уникальный ключ, каждая следующая вставка перезапишет предыдущую. Дальше нужно рыть доки - можно ли включить хранение дубликатов и т.д.
> У всех поведение по дефолту - уникальный ключ, каждая следующая вставка перезапишет предыдущую.
И это именно то, что я написал, и что Вам нужно!
Т.е. ключом там будет login+password, значением — source, так?
А потом нужна поддержка поиска по префиксу (т.е. в SQL это было бы "WHERE login_password LIKE 'login%'"), неужели в большинстве этого нет?
И это именно то, что я написал, и что Вам нужно!
Т.е. ключом там будет login+password, значением — source, так?
А потом нужна поддержка поиска по префиксу (т.е. в SQL это было бы "WHERE login_password LIKE 'login%'"), неужели в большинстве этого нет?
ЯТ
Yaroslav Schekin
> У всех поведение по дефолту - уникальный ключ, каждая следующая вставка перезапишет предыдущую.
И это именно то, что я написал, и что Вам нужно!
Т.е. ключом там будет login+password, значением — source, так?
А потом нужна поддержка поиска по префиксу (т.е. в SQL это было бы "WHERE login_password LIKE 'login%'"), неужели в большинстве этого нет?
И это именно то, что я написал, и что Вам нужно!
Т.е. ключом там будет login+password, значением — source, так?
А потом нужна поддержка поиска по префиксу (т.е. в SQL это было бы "WHERE login_password LIKE 'login%'"), неужели в большинстве этого нет?
Да, примерно так. Тогда это уже не b-tree индекс. В couchbase вроде нашёл что-то типа того. Вопрос опять же, сколько времени такой индекс будет строиться и сколько места займёт - мб даже хуже, чем в постгресе окажется
YS
Да, примерно так. Тогда это уже не b-tree индекс. В couchbase вроде нашёл что-то типа того. Вопрос опять же, сколько времени такой индекс будет строиться и сколько места займёт - мб даже хуже, чем в постгресе окажется
> Тогда это уже не b-tree индекс.
Да почему (и в PostgreSQL работает, кстати — как и должно)?!
Да почему (и в PostgreSQL работает, кстати — как и должно)?!
ЯТ
Yaroslav Schekin
> Тогда это уже не b-tree индекс.
Да почему (и в PostgreSQL работает, кстати — как и должно)?!
Да почему (и в PostgreSQL работает, кстати — как и должно)?!
ну, там хоть и написано
но на практике у меня всегда выходил фуллскан
The optimizer can also use a B-tree index for queries involving the pattern matching operators LIKE and ~
но на практике у меня всегда выходил фуллскан
YS
ну, там хоть и написано
но на практике у меня всегда выходил фуллскан
The optimizer can also use a B-tree index for queries involving the pattern matching operators LIKE and ~
но на практике у меня всегда выходил фуллскан
И правильно написано. Почему в какой-то ситуации был seq. scan — это другой вопрос.