Как правильно организовать поиск по большому кол-во бд?

Question

[Caxa]

Есть несколько больших postgresql таблиц(по ≈ 1млн строк в каждой). Например с номерами телефонов и информации о их владельцах.
Пользователь вводит номер, ему выдаётся инфа из бд.
Как сделать поиск максимально производительным? Что использовать? Асинхронность? Многопоточность?

Comments

[shurshur]

1 миллион это не так уж и много. Часто можно и просто в одну базу положить.

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

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

[d'Ivan]

Один и тот же номер искать сразу в нескольких СУБД?
В рамках какого типа архитектуры программы? Веб-сервер или что-то другое?

Как сделать поиск максимально производительным?

Какие требования к производительности?

[Модератор]

Не надо ставить как можно больше тэгов. Лучше оставить один, но конкретный, с которым проблема.
См.п.3.1 Регламента. Также обратите внимание на п.3.2

[d'Ivan]

Caxa , а какой опыт имеется в программировании вообще и в работе с СУБД? С какими объёмами данных сталкивался ранее?

Answer 1

[ThunderCat]

Как сделать поиск максимально производительным?

Вопрос из серии "какая машина самая крутая?". Нет решения которое подходит под любой вариант базы и структуры, иначе все только одним им и пользовались, логично?

Есть несколько больших postgresql таблиц(по ≈ 1млн строк в каждой).

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

Пользователь вводит номер, ему выдаётся инфа из бд.

Ну так сами пробовали сделать 20-30 рандомных запросов и посмотреть скорость, explain, использование индексов? Или мы "боимся заранее"?

Что использовать? Асинхронность? Многопоточность?

Мозги, используйте мозги, это гораздо эффективнее...

Answer 2

[mayton2019]

Как сделать поиск максимально производительным? Что использовать? Асинхронность? Многопоточность?

Оптимизация запроса к БД начинается с того что вы выделяете сет активных запросов которые важны для вас.
Для каждого из них строите план исполнения запросов
EXPLAIN [ ANALYZE ] [ VERBOSE ] ......
Потом с этим планом приходите к специалисту (или сюда) и спрашиваете что надо улучшить в
тексте запроса или в таблице или в индексе чтоб было быстрее.

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

Насчет асинхронных операций - не знаю. Если мы работаем через пул коннектов - то надо обсудить
построение абстракции асинхронности над абстракцией пула. Это тема отдельного топика.

Answer 3

[calculator212]

Есть несколько больших postgresql таблиц(по ≈ 1млн строк в каждой).

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

Comments

[mayton2019]

Если таблица проиндексирована и план - оптимален - то там хоть миллион хоть 10 миллионов для Postgres-индекса будут почти всегда означать 4 или 5 IOPS. А если используем SSD то эти иопсы сразу стоят на порядок дешевле.

Answer 4

[Vitsliputsli]

Есть несколько больших postgresql таблиц(по ≈ 1млн строк в каждой).

Слейти их все в одну таблицу и не нужен вам никакой параллелизм.