Результаты нескольких тестов производительности PostgreSQL:
- Тестирование (http://geomapx.blogspot.com/2009/12/postgresql-83.html) PostgreSQL 8.3 на больших таблицах: 10М записей;
- Тестирование (http://geomapx.blogspot.com/2009/12/postgresql-83-40.html) PostgreSQL 8.3 на больших таблицах: 40М записей;
- Тестирование (http://geomapx.blogspot.com/2009/12/postgresql-83-40_04.html) PostgreSQL 8.3 на больших таблицах: 40М записей и ограничение ОЗУ;- Сравнение (http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-...) скорости работы реального приложения при использовании PostgreSQL 8.1 и SQLite 3.6.20.
URL: http://geomapx.blogspot.com/2009/12/postgresql-83.html
Новость: http://www.opennet.me/opennews/art.shtml?num=24540
а почему не сравнивали с ораклом каким нибудь, или на худой конец с файербёрдом?
Почему графика нет на котором сразу понятно что и как работает.
А читать эту хрень нет желания
> а почему не сравнивали с ораклом каким нибудь, или на худой конец с файербёрдом?Сейчас интереснее неадминистрируемые СУБД, и те, которые можно легко перемещать между хостами. Опять же, нагрузка на самое узкое место - подсистему ввода-вывода для проектов на SQLite на порядки ниже. С одной стороны, есть ограничение, что кол-во модифицирующих транзакций в секунду ограничено примерно сотней, с другой стороны - максимальная нагрузка на жесткий диск заранее известна и перегрузки не будет. Если учесть, что при средней нагрузке в два десятка модифицирующих транзакций в секунду за год получается база в десятки гигабайт, то становится понятно - для большинства проектов этого достаточно (и нужен всего лишь один винт 10 000 rpm, так что зеркало через drbd можно держать на другой машине, и это надежнее получается, чем просто зеркальный рэйд).
В классе клиент-серверных СУБД вместо того, чтобы удвоить производительность, добавив второй идентичный хост, приходится использовать вдесятеро более дорогой сервер. Или, если проект допускает, несколько серверов с репликацией между ними, что опять же не дает линейного масштабирования, да еще и значительно усложняет администрирование.
Извините, это какой-то поток сознание про "перегрузку жёстких дисков".Есть куча нюансов использования sqlite. Оно не всегда и не везде быстрее и возможности очень скромны. В некоторых случаях целесообразнее вообще применять нереляционные БД.
1) `select ... from ... where ... in ( select ... )' - за такую конструкцию смело можно не читать статью.2) если грамотно вдуплиться в реальность бытия - то станет ясно, что все подается в сравнении. к примеру - с другой бд, с другим администратором/архитектором бд и пр. из известных мне бд оракл чуть бы не единственный, который учитывает все возможные глубины некомпетентности разработчиков - и старается компенсировать это хардкодом, исправляющим типовые ошибки.
3) никогда бы не додумался, но один человек как-то ответил на вопрос причины категорического предпочтения постгресу - мускуль: при сотнях тысяч таблиц - мускуль работает быстрее. Этот пример можно записать как еще один камень в огород постгреса, или просто тупо погоревать над глупостями некторых. Я предпочел поржать...
4) п.3 - для сравнения.
5) не читал статью - только пробежался взглядом - если появится ответ - посмотрю - отвечу.
Хм, а почему "за такую конструкцию смело можно не читать статью" В высшей степени часто употребляемая конструкция имеющая различные аспекты. ???
Вы не любите кошек? Да вы просто не умеете их готовить!PS Это про чушь по п.3. На заборе тоже написано..
Чего сравнивать, кому не нравится пусть покупают Oracle. DrNo правильно сказал, тут уж добавить нечего.
а там гораздо лучше с производительностью, судя по пресс-релизу. Его бы потестировали.
Глупое сравнение с QSLite. Она же не сервер, а эмбедед.
Нужно сравнивать с сервера с сопоставимой архитектурой.