Зависит от задачи. Вообще открытие базы занимает около 150 микросекунд, так что при использовании php это время вы никогда и не заметите.

Что касается борьбы с блокировками - сколько у вас модифицирующих запросов в секунду? Если не более нескольких десятков, обычно достаточно обеспечить быстрые селекты. Хинт: десяток модифицирующих запросов в секунду это примерно 10 миллионов отображаемых веб-страниц в сутки, очень сомневаюсь, что у вас подобные масштабы системы и нужно об этом беспокоиться.

Другой вопрос - какого размера у вас БД? Вот это уже серьезно, т.к. работа с эскулайт БД размером более нескольких Гб становится сложной. Скажем так - или вы делаете большую, но простую БД с парой таблиц, или небольшую, но сколь угодно сложную.

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

SeratorРеально ограничений нет. Посещаемость, характеристики железа, размер бд заранее неизвестны.

В таком виде задача не имеет решения. Сделать аналог гугла на компьютере Pentium I не получится.

SeratorЗадача состоит в том, что при различных вариациях количества компонентов / посещаемости / размера бд и прочего, производительность не страдала (понимаю, что здесь нужно рассматривать на конкретных ситуациях, но пока нет возможности их модулировать). Я вижу это в разбитии единой базы на несколько. В итоге мы получим в случаи записи блокировку фактически таблицы, а не всей базы.

Еще раз - я не думаю, что у вас возникнет проблема с блокировками. Скорее, будут сложности с медленной вставкой на больших таблицах. Как пример, на таблице, содержащей 10 миллионов записей, скорость вставки может замедляться от 10 до 100 раз, в зависимости от созданных индексов. Зачастую имеет смысл хранить сериализованные структуры данных, делая по ним полнотекстовый поиск, вместо создания огромных таблиц. Используйте сжатие, в том числе для модуля полнотекстового поиска, подбирайте настройки СУБД и так далее.

Почитайте для начала архивы рассылки sqlite-users, там много интересного обсуждается. В том числе использование эскулайт на кластерах, большие БД и многое другое.

Serator
Какие подводные камни могут встретиться при использовании данного подхода?

Нарушение целостности. Подумайте про view и триггеры, которые должны будут работать с несколькими БД. Обратите внимание, что их код будет невалиден, если нужные БД не подключены.

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

Сам я использую разделение базы на несколько - но не так, как это хотите делать вы...

Serator
А вот с памятью возможны какие-либо проблемы?

А вы мои тесты смотрели? Все не все, но многие проблемы описаны и измерены:
http://geomapx.blogspot.com/search/label/SQLite

Serator
MBGА вы мои тесты смотрели?

Смотрел, только ответа в том или ином виде не нашел.

В зависимости от используемых индексов нужно мало или много памяти. Сколько именно для тех или иных индексов - см. тесты.

White OwlРезать реляционные базы на отдельные таблицы ради производительности нет смысла, потому что для такого есть специальные типы баз данных. Называются flat-file databases.

Если желаешь хранить таблицы отдельно друг от друга, то и смотри соотвествнно в сторону BerkleyDB или ее кузенов.

Не соглашусь. Пример - корпоративный телефонный биллинг на эскулайт, ежемесячно миллионы звонков обрабатываются. Если хранить все звонки в одной БД, производительность будет в разы падать на каждые 10 миллионов записей, а разделив данные трафика по месяцам, получаем очень шуструю систему. Я уже как-то приводил цифры - система биллингует 1 миллион звонков в минуту на процессоре кореквадро, поддерживается репликация, синхронный и асинхронный режимы биллингования и проч. Скорость построения отчетов для пользователей тоже высокая и заранее известна, поскольку месячный объем данных оценить не составляет сложностей. Кроме того, отсутствуют блокировки - все настройки биллинга и данные о пользователях, тарифах, etc. хранятся в отдельной базе и процесс биллингования эту базу не блокирует.

White OwlЭто немножко другая задача. Serator хочет разбить базу на отдельные таблицы. А вы говорите про сегментирование данных. Это две очень большие разницы.

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

Serator
MBG, про память я имел ввиду издержки именно на сами БД (к примеру 1 база и несколько с идентичными данными)

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

Serator
Получается существенных проблем в данном решении и его можно использовать, так?

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

Уточняю:


Это код на языке Tcl, смысл в том, что все операции с БД делаем по возможности краткими, а продолжительную обработку выполняем на временных таблицах. Ориентировочно до 10 000 одновременных веб-пользователей такой техники достаточно.

SeratorХм, а в какой ситуации оно может понадобиться? Ибо блокировка будет на время записи, а здесь обрабатывать-то по сути нечего.

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

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

Теперь понятно, почему нет нужды бороться с блокировкой чтения при записи?

SeratorХм, я пытаюсь свести к минимуму издержки на блокирование. К примеру имеем 2 таблицы. Если будем писать больше в первую, а из второй больше читать, то нет смысла блокировать вторую, так ведь? На деле же получится тоже самое, только в больших масштабах.

На деле получится так, что вы раньше упретесь в предел по числу пишущих транзакций - то есть в иную проблему. Если же вам удастся сделать все операции записи кратковременными - порядка единиц мс на каждую, притом, что на 10 000 RPM диске больше 100 транзакций в секунду не получить, и операции чтения порядка единиц-десятков мс, то вы избежите всех проблем.

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

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

SeratorКопия базы, это хорошо, но мне нужна актуальная информация при каждом запросе и сей подход не подойдет. По ограничению транзакций вы тоже правы, но все же эти ограничения более отдаленные, нежели ограничения с блокировками. Наверное правильным подходом на данном этапе будет оставить все как есть (1 база), а в случае проблем решать их, но хочется все же заранее предотвратить большинство проблем, ибо в дальнейшем переделывать придется гораздо больше (если придется вообще).

В определенных случаях возможно использовать базы в 100 Гб при конкурентном доступе, а в других ситуациях проблемы возникают уже на базах в 1 Гб при однопользовательской работе. Тестируйте, делайте - и не бойтесь менять архитектуру; все известные крупные проекты меняли архитектуру много раз.

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