форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Тестирование производительности PostgreSQL"		+/–
Сообщение от opennews (ok) on 05-Дек-09, 10:56
Результаты нескольких тестов производительности 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
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Тестирование производительности PostgreSQL"		+/–
Сообщение от gordev (ok) on 05-Дек-09, 10:56
а почему не сравнивали с ораклом каким нибудь, или на худой конец с файербёрдом?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Тестирование производительности PostgreSQL"		+1 +/–
Сообщение от Аноним (??) on 05-Дек-09, 12:30
Почему графика нет на котором сразу понятно что и как работает. А читать эту хрень нет желания
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Тестирование производительности PostgreSQL"		+/–
Сообщение от Veter (??) on 05-Дек-09, 15:14
> а почему не сравнивали с ораклом каким нибудь, или на худой конец с файербёрдом? Сейчас интереснее неадминистрируемые СУБД, и те, которые можно легко перемещать между хостами. Опять же, нагрузка на самое узкое место - подсистему ввода-вывода для проектов на SQLite на порядки ниже. С одной стороны, есть ограничение, что кол-во модифицирующих транзакций в секунду ограничено примерно сотней, с другой стороны - максимальная нагрузка на жесткий диск заранее известна и перегрузки не будет. Если учесть, что при средней нагрузке в два десятка модифицирующих транзакций в секунду за год получается база в десятки гигабайт, то становится понятно - для большинства проектов этого достаточно (и нужен всего лишь один винт 10 000 rpm, так что зеркало через drbd можно держать на другой машине, и это надежнее получается, чем просто зеркальный рэйд). В классе клиент-серверных СУБД вместо того, чтобы удвоить производительность, добавив второй идентичный хост, приходится использовать вдесятеро более дорогой сервер. Или, если проект допускает, несколько серверов с репликацией между ними, что опять же не дает линейного масштабирования, да еще и значительно усложняет администрирование.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Тестирование производительности PostgreSQL"		+/–
	Сообщение от Одмин on 07-Дек-09, 16:11
	Извините, это какой-то поток сознание про "перегрузку жёстких дисков". Есть куча нюансов использования sqlite. Оно не всегда и не везде быстрее и возможности очень скромны. В некоторых случаях целесообразнее вообще применять нереляционные БД.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Тестирование производительности PostgreSQL"		+/–
Сообщение от parad (ok) on 05-Дек-09, 20:28
1) `select ... from ... where ... in ( select ... )' - за такую конструкцию смело можно не читать статью. 2) если грамотно вдуплиться в реальность бытия - то станет ясно, что все подается в сравнении. к примеру - с другой бд, с другим администратором/архитектором бд и пр. из известных мне бд оракл чуть бы не единственный, который учитывает все возможные глубины некомпетентности разработчиков - и старается компенсировать это хардкодом, исправляющим типовые ошибки. 3) никогда бы не додумался, но один человек как-то ответил на вопрос причины категорического предпочтения постгресу - мускуль: при сотнях тысяч таблиц - мускуль работает быстрее. Этот пример можно записать как еще один камень в огород постгреса, или просто тупо погоревать над глупостями некторых. Я предпочел поржать... 4) п.3 - для сравнения. 5) не читал статью - только пробежался взглядом - если появится ответ - посмотрю - отвечу.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Тестирование производительности PostgreSQL"		–1 +/–
	Сообщение от tmc on 05-Дек-09, 21:19
	Хм, а почему "за такую конструкцию смело можно не читать статью" В высшей степени часто употребляемая конструкция имеющая различные аспекты. ???
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Тестирование производительности PostgreSQL"		+/–
	Сообщение от DrNo (??) on 05-Дек-09, 22:23
	Вы не любите кошек? Да вы просто не умеете их готовить! PS Это про чушь по п.3. На заборе тоже написано..
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Тестирование производительности PostgreSQL"		+/–
Сообщение от alexmest (ok) on 06-Дек-09, 02:49
Чего сравнивать, кому не нравится пусть покупают Oracle. DrNo правильно сказал, тут уж добавить нечего.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "А чего 8.3-то тестировать? С ним все ясно. 8.4 давно вышел"		+/–
Сообщение от phil (??) on 06-Дек-09, 03:34
а там гораздо лучше с производительностью, судя по пресс-релизу. Его бы потестировали.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Тестирование производительности PostgreSQL"		+/–
Сообщение от trdm (ok) on 06-Дек-09, 13:44
Глупое сравнение с QSLite. Она же не сервер, а эмбедед. Нужно сравнивать с сервера с сопоставимой архитектурой.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема