我想知道Redbean ORM是否可以用于性能导向的场景,如社交网络Web应用程序等。如果多个用户同时拉取数千个数据,它是否稳定。此外,我想知道Redbean是否会消耗更多的内存空间。
是否有人可以提供Doctrine-Propel-Redbean的比较研究?
我想知道Redbean ORM是否可以用于性能导向的场景,如社交网络Web应用程序等。如果多个用户同时拉取数千个数据,它是否稳定。此外,我想知道Redbean是否会消耗更多的内存空间。
是否有人可以提供Doctrine-Propel-Redbean的比较研究?
我认为 Tereško 的回答并不完全正确。
首先,它没有解决原问题。这确实是反ORM的一个案例,我同意他在回答中描述的问题。这就是为什么我写了 RedBeanPHP。只是因为大多数ORM无法使你的生活变得更容易,这并不意味着对象关系映射系统的概念有缺陷。大多数ORM试图隐藏SQL,这就是为什么JOIN变得如此复杂的原因;它们需要在面向对象的环境中重新发明类似的东西。这就是 RedBeanPHP 的不同之处,因为它不隐藏SQL。它创建可查询的可读、有效的SQL表格。RedBeanPHP 使用普通的SQL进行记录和bean检索,而不是虚构的查询语言。简而言之,RedBeanPHP 与SQL共同工作,而不是相互对立。这使它变得不那么复杂。
是的,RedBeanPHP 的性能很好。我怎么这么肯定?因为与其他ORM不同,RedBeanPHP区分开发模式和生产模式。在开发周期中,数据库是流动的;您可以添加条目,并且它们将被动态添加。RedBeanPHP 创建列、索引、猜测数据类型等。甚至在一段时间后,如果需要更多字节(更高的数据类型),它也可以拉伸列。这使得 RedBeanPHP 在开发时间极其缓慢,但速度不应是一个问题。完成开发后,使用单个模式指定器 R::freeze() 冻结数据库,不再进行任何检查。您所剩下的就是在生产服务器上的一个非常简单的数据库层。因为没有做太多事情,所以性能很好。
是的,我知道,我是RedBeanPHP的作者,所以我有偏见。然而,我觉得我的ORM被视为其他ORM一样,这促使我写这篇文章。如果您想了解更多信息,请随时参考RedBeanPHP网站,这里是关于性能的讨论。
在我们公司,我们在嵌入式系统和金融业务系统中使用RedBeanPHP,所以它似乎相当可扩展。
我和RedBeanPHP社区一起真诚地努力使ORM世界变得更好;你可以在这里阅读任务声明。
祝你的项目好运,希望你找到你要寻找的技术解决方案。
@tereško如果可能的话,您能根据您的经验列出ORM相对于纯SQL的优缺点吗?同时我也会在谷歌上搜索这个主题。- Jaison Justus
嗯...用600个字符来解释这个问题很难。
我必须澄清一件事:这是关于PHP中的ORMs,虽然我很确定它也适用于某些Ruby ORMs和其他一些ORMs。
简而言之,你应该避免使用ORMs,但是如果你必须使用ORM,则最好选择Doctrine 2.x,它是较小的邪恶。(实现了类似于DataMapper而不是ActiveRecord的东西)。
一些开发人员喜欢使用ORMs的主要原因也是它们最糟糕的地方:在ORM中执行简单操作很容易,性能成本非常低。这完全没问题。
1. 指数复杂度
问题源于人们将同一工具用于所有事情。这导致创建technical debt。
起初编写新的数据库相关代码很容易。也许,因为你有一个大项目,在前几周管理层决定雇用更多人员(因为后来会引起其他问题——如果对细节感兴趣,请阅读神话般的人月)。最终,你会更喜欢具有ORM技能而不是一般SQL的人。*
来选择数据。当你只需要文章ID和标题列表时,获取内容就没有意义。附言:还有其他原因和副作用,但它们相对较小...现在无法记起任何其他重要问题。
我在这里与 @tereško 不同 - ORM 可以使数据库查询更容易编写和维护。在我的观点中,Propel 和 Doctrine 都有一些出色的工作 - 请利用它们!网络上有很多性能比较,并且也要检查 NotORM(我没有使用过,但如果我记得正确,它们进行了一些和 Doctrine 的比较)。
如果你到达一个需要使用原始SQL的吞吐量点,那么在那个时候进行优化。但是从减少错误数量和提高生产效率的角度来看,我认为你的节省会为更好的服务器提供资金。当然,你的收益可能因情况而异。
顺便说一下,我不认识 RedBean,但我觉得 Propel 在大多数情况下比 Doctrine 更快,因为类是预先生成的。当 Propel 是唯一的选择时,我使用了它,并坚持使用它,尽管我肯定不排斥使用 Doctrine。
经过多年开发,Propel 2 仍处于 alpha 版本,需要进行多项重大重构项目,但遗憾的是,这些项目并未得到解决。虽然维护者称此 alpha 版本具有良好的测试覆盖率,可以在生产中使用,但他们现在已经开始开发 Propel 3。不幸的是,在我撰写本文时,这个版本尚未发布,尽管代码库已经一岁了。
虽然我认为 Propel 是一个很棒的项目,但我想暂时最好使用其他东西。它可能会再次崛起!
我会选择“因地制宜”的做法,采用两个世界的混合搭配。我使用RedBean构建了一些大型应用程序,因此我的评论将纯粹集中在RedBean上,而不是其他ORM。
RedBean ORM速度慢吗?
这取决于你如何使用它。在某些情况下,它比传统查询更快,因为RedBean会缓存结果几秒钟。重复使用查询将产生更快的结果。查看日志使用R::debug(true);
它总是显示:
"SELECT * FROM `table` -- keep-cache"
场景1:获取全部数据(*)
在RedBean中,如果您进行查询:
$result = R::findOne('table', ' id = ?', array($id));
这被表示为
$result= mysql_query("Select * from TABLE where id =".$id);
你可能会争辩说,如果这个表有多列,为什么你要查询(*)。
情景2:单列
获取单列数据
R::getCol( 'SELECT first_name FROM accounts' );
就像我提到的“因地制宜”,开发人员不应只依赖于FindOne、FindAll、FindFirst、FindLast
,而应该仔细草拟他们真正需要的内容。
场景3:缓存
当您不需要缓存时,可以在应用程序级别禁用缓存,但这并不是理想的情况。
R::$writer->setUseCache(true);
RedBean建议,如果您不想在应用程序级别禁用缓存,则应使用传统查询来获取没有缓存参数的结果,如$result = R::exec("SELECT SQL_NO_CACHE * FROM TABLE");
这完美地解决了从表中提取实时数据的问题,通过完全丢弃查询缓存。
场景4:快速开发
使用ORM使您的应用程序开发非常快速,开发人员可以使用ORM编码比编写SQL快2-3倍。
场景5:复杂查询和关系
RedBean提供了一种实现复杂查询和一对多
或多对多
关系的非常好的方法。
使用纯SQL进行复杂查询
$books = R::getAll( 'SELECT
book.title AS title,
author.name AS author,
GROUP_CONCAT(category.name) AS categories FROM book
JOIN author ON author.id = book.author_id
LEFT JOIN book_category ON book_category.book_id = book.id
LEFT JOIN category ON book_category.category_id = category.id
GROUP BY book.id
' );
foreach( $books as $book ) {
echo $book['title'];
echo $book['author'];
echo $book['categories'];
}
OR RedBean处理多对多关系的方式
list($vase, $lamp) = R::dispense('product', 2);
$tag = R::dispense( 'tag' );
$tag->name = 'Art Deco';
//creates product_tag table!
$vase->sharedTagList[] = $tag;
$lamp->sharedTagList[] = $tag;
R::storeAll( [$vase, $lamp] );
性能问题
通常类似ORM这样的参数会使得应用程序变慢、消耗更多内存。但我认为这种情况不适用于RedBean。
我们已经在MySQL和Postgres上进行了测试,相信我,性能从来都不是瓶颈。
毋庸置疑,ORM会增加一些开销并会使得应用程序变慢(只是一点点)。使用ORM主要是为了在开发时间和轻微降低运行时性能之间进行权衡。我的策略是首先使用ORM构建应用程序,然后根据测试用例调整关键速度模块以使用直接数据访问。