Каким образом организовать хранение большого количества записей в БД?

Question

[Илья]

Ситуация следующая. Есть БД (SQLite, Windows) с одной таблицей, в которой всего три столбца:
- Идентификатор записи (текст, уникальный)
- Email владельца (нормализованные)
- Дополнительный текст (может быть весьма объёмным)

Выполняемые операции:
- Добавление новых записей
- Проверка наличия идентификатора в таблице (чтобы не допустить дублей)
- Выборка записей по email

С малым количеством данных никаких проблем не было. Но сейчас БД разрослось до 15 гигабайт и всё ворочается очень медленно. С записью проблем нет, а вот запросы на выборку по email могут длиться минутами. И каждый запрос на чтение блокирует таблицу для записи, что критично.

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

Answer 1

[Андрей Ежгуров]

Проще переехать на любую нормальную SQL-базу (начиная с MySQL) с индексами для столбцов идентификатор и e-mail. Там такие запросы будут выполняться быстро.

Comments

[Илья]

PostgreSQL подойдёт?

[Андрей Ежгуров]

Безусловно.

[Илья]

Я правильно понимаю, что одновременная запись и запросы к БД (а также параллельное выполнение множества запросов) в случае с PostgreSQL будут выполняться нормально безо всяких шаманств?

Answer 2

[KorsaR-ZN]

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

пример:

table1:
  id, key, email, text_id

table2:
  id, text

и расширте мой вариан ответом от @Fesor

Comments

[Илья]

А text_id в table1 не лишний? Я же по id их уже связал?

[KorsaR-ZN]

@Gorily Ну тут id - это идентификатор записи в конкретной таблицы,
text_id - это идентификатор записи в таблицы table2

т.е тут получается один-к-многим, т.е один текст и несколько его авторов.
Ну я в качестве примера привел, а так связку email -> text сделайте, как Вам удобнее.

[Sali_cat]

@KorsaR-ZN ДА вот тоже было интересно.. У меня есть база с 13 колонками (3 из них хранят массивы.. ) Стоит ли их разбивать на подобные фрагменты? Если в 1м случаи грузится лишь 5 столбиков, а во 2м уже все. Надо тесты произвести:D Не знаешь как ?

[KorsaR-ZN]

@Sali_cat Ну 13 колонок это не так много, но все-равно что-то тут наверное не так :)
Тем более если 3 из них хранят массивы, я так понимаю это json или сериализация, то твоя табличка будет быстро разрастаться в размере.

Так что почитай про нормализацию БД.
Привиди к первой форме точно, но желательно к второй.
Хотя если таблица не сильно нагруженная будет по запросам, да и проект простой, то не парся оставь, как есть :)

[KorsaR-ZN]

@Sali_cat Произвести денормализацию будет проще, чем нормализацию уже на работающем проекте...

[Sali_cat]

@KorsaR-ZN Да я не знаю чего ожидать.. Мне нравится свой продукт) А я такой человек.. что делаю сам не всегда нравится мне за-то другим.. и пару случаев что бы мне самому нравилось.. Позже ссылку на оф. сайт кину) Домен кстати прикольный вырвал 4х символьный) Скоро это уже такой редкостью будет

[KorsaR-ZN]

@Sali_cat Размытый какой-то ответ, я из него ничего не понял :), но думаю все хорошо :D, про нормализацию почитайте все же:)

[Sali_cat]

@KorsaR-ZN Вечером) Спасибо)

Answer 3

[Alex Chistyakov]

Не надо пытаться использовать SQLite для таких задач - для конкурентной работы он, к сожалению, не предназначен вообще. Это встраиваемая база данных.

Comments

[Илья]

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

Answer 4

[Сергей Протько]

www.sqlite.org/lockingv3.html
+ uniq индексы

Comments

[Илья]

Uniq индексы подойдут для столбца идентификатора. А что делать для столбца email?