Альтернативы DbSimple

Question

[deleted-mezhevikin]

Уже год, как пользуюсь в своих проектах DbSimple, но для высоконагруженных проектов хотелось бы что нибудь побыстрее. Что посоветуете?

Comments

[Сергей]

Кстати, для общего развития интересуюсь — чем PDO не подходит?

[deleted-mezhevikin]

а кто сказал что не подходит?

[Сергей]

Да просто когда писал комментарий у комментария DevMan про PDO минус стоял…

[deleted-mezhevikin]

мне понравился PDO, он действительно самый быстрый по тестам, однако по функционалу проигрывает dbsimple

[DevMan]

Не могли бы вы рассказать что именно есть в dbsimple, чего нет в PDO?

Answer 1

[DevMan]

PDO — быстрее некуда, да и удобно.

Answer 2

[gro]

Обычно прослойка создаёт совершенно ничтожную нагрузку по сравнению с самим запросом.
Из альтернатив DbSimple: pyha.ru/go/godb/, code.google.com/p/go-db/

Comments

[deleted-mezhevikin]

интересная штуку, правда нигде не нашел каких либо цифр в плане производительности

Answer 3

[sajgak]

Для хайлоада желательно использовать чистые SQL запросы. Конечно небольшая прослойка для удобства нужна… аля $this->db->query(); $this->db->escape()… Но все что больше — лишнее. И вообще в высоконагруженных проектах лучше отказаться от мускуля)

Comments

[Евгений]

Ага, facebook, friendfeed, quora, и другие — просто ошибаются.
Да и ORM никто не использует. Чем вам так ORM не угодил? Неужели такая большая разница с написанным вручную запросом? Нормальный ORM обычно позволяет построить практически любой запрос, разница с написанным вручную — минимальная. В худшем случае будет лишний JOIN или браться несколько лишних полей — это незаметные копейки в потере производительности.

[sajgak]

Насчет того, ошибаются ли они — не знаю, возможно им просто лень перепрограммировать бекенды:) Хотя как известно тот же фейсбук не использует все возможности mysql и все данные у него хранятся исключительно как «ключ-значение»… а для этого намного лучше подходит любая nosql база. Почему они на мускуле — ответ не ясен. Как минимум использование PostgreSQL уже дает некий прирост, хотя я все же за nosql решения (там, где они действительно применимы). «Лишний джоин или несколько лишних полей» — я бы посмотрел на крупицу в потере производительности при джоуне нескольких таблиц с парой милионов записей в каждой:). Я не говорю, что ORM зло — каждый решает сам, чем ему удобнее пользоваться. Существуют так же качественные CRUD решения, их тоже удобно использовать. Но вопрос стоял — с использованием чего получим наивысшую проивзодительность.
Ну и напоследок — список тех, кто не ошибается:)

[sajgak]

MongoDD: www.mongodb.org/display/DOCS/Production+Deployments
CouchDB: ru.wikipedia.org/wiki/CouchDB#.D0.98.D1.81.D0.BF.D0.BE.D0.BB.D1.8C.D0.B7.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_CouchDB

это то, что нашел по быстрому. Как минимум список у MongoDB впечатляет

[Евгений]

Как разработчик одного из высоконагруженных серверов могу сказать, что ORM ничуть не мешает. Правда, использую PostgreSQL, а не MySQL, но думаю, не суть важно.

Неэффективные запросы генерируются редко и обычно ситуацию можно исправить не прибегая к сырому SQL. Ну что там такого можно наворотить на голом SQL, что нельзя сделать в ORM? Да почти ничего.

Лишние JOIN'ы написал для примера, такие случаи в практике бывали, но редко, и не оказывали влияния на производительность. Если ORM джойнит таблицу с миллионами записей, когда это не нужно, то на помойку надо отправлять именно эту реализцаию ORM, а не всю концепцию в целом.

По поводу NoSQL: полагаю, что на каждый пример этих деплойментов, найдутся тысячи, даже десятки тысяч аналогичных проектов на SQL. Мне казалось, что общепринятое мнение сейчас, что NoSQL не стали очередной серебряной пулей. Где-то они лучше, где-то хуже, где-то равны.

[sajgak]

Ну так никто никого никуда и не выбрасывает. Используйте, где это не кретично в плане производительности — ORM, CRUD, все что угодно и удобно конкретно вам или вашей команде. Переписывайте на SQL узкие места и переходите на nosql там, где это даст значительную прибавку. Ну а если единственной вашей целью является производительность — читайте выше.

Answer 4

[pav]

А есть замеры/цифры которые доказывают что DbSimple будет являться узким местом в нагруженных проектах?

Comments

[deleted-mezhevikin]

ну вот тут он показал себя хуже всего habrahabr.ru/blogs/php/27853/.
И если не ошибаюсь сам Котеров говорил, что DbSimple не очень хороша для больших проектов.

Answer 5

[developer]

Да, нигде не видел ничего лучше select *, id AS ARRAY_KEY from table where 1 {and field=?d} тоже очень хотел бы видить современный аналог или этот бы переписал кто.

Comments

[deleted-mezhevikin]

после создания моего вопроса прошло уже пару месяцев, в своем дипломе по совету я использовал godb, показала себя очень даже неплохо, работает быстро при выборке больших объемов данных

[deleted-mezhevikin]

нашел баг, тег hh в вопросах парсер кушает

[ZverenOk]

Для больших данных нужно использовать только MYSQLI_USE_RESULT а функции работы с базой должны просто плейсхолдеры правильно подставлять и всё

Answer 6

[ozon]

dibiphp.com/

Comments

[deleted-mezhevikin]

выглядит интересно, на след проекте попробую поюзать. спасибо

Answer 7

[Jazzist]

SQLite.

Просто, быстро, удобно. За базар отвечаю!

Если использовать через слой (что разумно всегда) — будет и вам счастье :)

Comments

[Jazzist]

Простите! Не въехал в суть вопроса и фигню ляпнул.

Ответ — PDO, или средство, предоставляемое фреймворком.