标签: database-performance

MySQL数据库在什么时候开始失去性能？

• 物理数据库大小是否重要？
• 记录数量是否重要？
• 任何性能下降是线性还是指数？

我有一个我认为是一个大型数据库,大约有15M的记录,占用了近2GB.基于这些数字,我是否有动力清理数据,或者我是否可以安全地继续扩展数年？

我正在做一个处理结构化文档数据库的项目.我有一个类别树(约1000个类别,每个级别最多约50个类别),每个类别包含数千个(最多,比方说,~10000)结构化文档.每个文档都是几千字节的数据,采用某种结构化形式(我更喜欢YAML,但它也可能是JSON或XML).

该系统的用户可以进行多种操作:

• 通过ID检索这些文档
• 通过其中的一些结构化属性搜索文档
• 编辑文件(即添加/删除/重命名/合并); 每个编辑操作都应记录为具有一些注释的事务
• 查看特定文档的记录更改历史记录(包括查看更改文档的人员,时间和原因,获取早期版本 - 如果需要,可能还原为此版本)

当然,传统的解决方案是使用某种文档数据库(例如CouchDB或Mongo)来解决这个问题 - 然而,这个版本控制(历史)的东西诱惑我一个疯狂的想法 - 为什么我不应该使用git存储库作为一个这个应用程序的数据库后端？

乍一看,它可以像这样解决:

• category = directory,document = file
• 通过ID获取文档=>更改目录+读取工作副本中的文件
• 使用编辑注释编辑文档=>通过各种用户进行提交+存储提交消息
• history =>正常的git日志和旧事务的检索
• search =>这是一个稍微棘手的部分,我想这需要定期将一个类别导出到关系数据库中,并对我们允许搜索的列进行索引

这个解决方案还有其他常见的陷阱吗？有没有人试图实现这样的后端(即任何流行的框架 - RoR,node.js,Django,CakePHP)？这个解决方案是否会对性能或可靠性产生任何影响 - 即它是否证明git比传统数据库解决方案慢得多,或者存在任何可扩展性/可靠性缺陷？我认为推送/拉取彼此存储库的这类服务器集群应该相当强大和可靠.

基本上,告诉我,如果这个解决方案将工作和为什么它会或不会做？

我一直在网上搜索为MongoDB Java驱动程序配置MongoOptions的最佳实践,除了API之外,我还没有提出太多其他方法.这个搜索在我遇到"com.mongodb.DBPortPool $ SemaphoresOut:Out of semaphores to get db connection"错误并且通过增加连接/乘数我能够解决该问题后开始.我正在寻找为生产配置这些选项的链接或最佳实践.

2.4驱动程序的选项包括:http: //api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html

• autoConnectRetry
• connectionsPerHost
• connectTimeout
• maxWaitTime
• 了socketTimeout
• threadsAllowedToBlockForConnectionMultiplier

较新的司机有更多的选择,我也有兴趣听到这些.

我们正在使用Postgresql 9.1.4我们的数据库服务器.我一直在努力加快我的测试套件的速度,所以我盯着db稍微分析一下,看看到底发生了什么.我们使用database_cleaner在测试结束时截断表.是的我知道交易更快,我不能在某些情况下使用它们所以我不关心它.

我关心的是,为什么TRUNCATION需要这么长时间(比使用DELETE更长)以及为什么它在我的CI服务器上需要更长时间.

现在,在本地(在Macbook Air上)一个完整的测试套件需要28分钟.拖尾日志,每次我们截断表...即:

TRUNCATE TABLE table1, table2  -- ... etc

执行截断需要1秒多的时间.在我们的CI服务器(Ubuntu 10.04 LTS)上记录日志,需要花费整整8秒才能截断表格,构建需要84分钟.

当我切换到:deletion策略时,我的本地构建花了20分钟,CI服务器下降到44分钟.这是一个显着的差异,我真的很惊讶为什么会这样.我已经调整 了 CI服务器上的数据库,它有16GB系统RAM,4gb shared_buffers ......和一个SSD.所有好东西.这怎么可能:

一个.它比我的Macbook Air慢了2gb
.当postgresql文档 明确指出它应该快得多时,TRUNCATION比DELETE慢得多.

有什么想法吗？

我正在尝试确定实体框架比存储过程慢多少.我希望说服我的老板让我们使用Entity Framework来简化开发.

问题是我进行了性能测试,看起来EF比Stored Procs慢大约7倍.我觉得这很难相信,我想知道我是否遗漏了什么.这是一个确凿的测试吗？有什么办法可以提高EF测试的性能吗？

        var queries = 10000;

        //  Stored Proc Test
        Stopwatch spStopwatch = new Stopwatch();
        spStopwatch.Start();
        for (int i = 0; i < queries; i++ )
        {
            using (var sqlConn = new SlxDbConnection().Connection)
            {
                var cmd = new SqlCommand("uspSearchPerformanceTest", sqlConn) { CommandType = CommandType.StoredProcedure };

                cmd.Parameters.AddWithValue("@searchText", "gstrader");
                sqlConn.Open();
                SqlDataReader dr = cmd.ExecuteReader();

                List<User> users = new List<User>();
                while (dr.Read())
                {
                    users.Add(new User
                    {
                        IsAnonymous = Convert.ToBoolean(dr["IsAnonymous"]),
                        LastActivityDate = Convert.ToDateTime(dr["LastActivityDate"]),
                        LoweredUserName = dr["LoweredUserName"].ToString(),
                        MobileAlias = dr["MobileAlias"].ToString(),
                        UserId = new …

我注意到这里有很多人在一个表中列出了20多个(我已经看到多达55个)列的表.现在我不假装成为数据库设计专家,但我总是听说这是一个可怕的做法.当我看到这一点时,我通常建议分成两个具有一对一关系的表:一个包含最常用的数据,另一个包含最少使用的数据.虽然同时存在性能问题(更少的JOIN等).所以我的问题是:

当谈到真正的大规模数据库时,拥有大量列实际上是否有优势,尽管这通常导致许多NULL值？

这更像是一个性能损失:很多列有很多NULL,或者有很多JOIN的列？

我们有一个大约70 GB的InnoDB数据库,我们预计它会在未来2到3年内增长到几百GB.大约60%的数据属于一个表.目前数据库运行良好,因为我们有一个64 GB RAM的服务器,所以几乎整个数据库都适合内存,但我们担心未来数据量会大得多.现在我们正在考虑某种方式来分割表格(尤其是占据数据最大部分的表格),我现在想知道,最好的方法是什么.

我目前知道的选项是

• 使用5.1版附带的MySQL分区
• 使用某种封装数据分区的第三方库(如hibernate分片)
• 在我们的应用程序中自己实现它

我们的应用程序基于J2EE和EJB 2.1构建(希望有一天我们可以切换到EJB 3).

你会建议什么？

编辑(2011-02-11):
只是一个更新:目前数据库的大小是380 GB,我们的"大"表的数据大小是220 GB,其索引的大小是36 GB.因此,虽然整个表不再适合内存,但索引确实如此.
系统仍然运行良好(仍然在相同的硬件上),我们仍然在考虑分区数据.

编辑(2014-06-04):还有一个更新:整个数据库的大小是1.5 TB,我们的"大"表的大小是1.1 TB.我们将服务器升级到具有128 GB RAM的4处理器机器(Intel Xeon E7450).该系统仍然表现良好.我们接下来要做的是将我们的大表放在一个单独的数据库服务器上(我们已经在我们的软件中进行了必要的更改),同时升级到具有256 GB RAM的新硬件.

这个设置应该持续两年.然后我们要么必须最终开始实施分片解决方案,要么只购买1 TB RAM的服务器,这应该让我们继续使用一段时间.

编辑(2016-01-18):

从那以后,我们将自己的大表放在单独的服务器上.目前,该数据库的大小约为1.9 TB,另一个数据库的大小(除了"大"之外的所有表)都是1.1 TB.

当前硬件设置:

• HP ProLiant DL 580
• 4 x Intel(R)Xeon(R)CPU E7- 4830
• 256 GB RAM

此设置的性能很好.

我在Innodb有一张超过1亿行的表.

我必须知道外键是否超过5000行= 1.我不需要确切的数字.

我做了一些测试:

SELECT COUNT(*) FROM table WHERE fk = 1=> 16秒
SELECT COUNT(*) FROM table WHERE fk = 1 LIMIT 5000=> 16秒
SELECT primary FROM table WHERE fk = 1=> 0.6秒

我将拥有更大的网络和治疗时间,但它可能是15.4秒的超载!

你有更好的主意吗？

谢谢

编辑:[添加了OP的相关评论]

我尝试了SELECT SQL_NO_CACHE COUNT(fk)FROM表WHERE fk = 1但是耗时25秒

使用Mysql Tuner调整了Mysod的Innodb.

CREATE TABLE table ( pk bigint(20) NOT NULL AUTO_INCREMENT,
fk tinyint(3) unsigned DEFAULT '0', 
PRIMARY KEY (pk), KEY idx_fk (fk) USING BTREE ) 
ENGINE=InnoDB AUTO_INCREMENT=100380914 DEFAULT CHARSET=latin1

DB Stuff:

'have_innodb', 'YES' 'ignore_builtin_innodb', …

我试图掌握数据库分区的不同概念,这就是我对它的理解:

水平分区/分片:将表拆分到不同的表中,该表将包含初始表中的行的子集(如果按大陆分割Users表,我已经看到了很多示例,如北美的子表,另一个为欧洲等...).每个分区位于不同的物理位置(了解"机器").据我所知,水平分区和分片是完全相同的(？).

垂直分区:根据我的理解(http://technet.microsoft.com/en-us/library/ms178148%28v=sql.105%29.aspx),有两种垂直分区:

• 规范化(包括通过拆分表并使用外键链接来从数据库中删除冗余).

• Row Splitting,这是我不明白的,Normalization和Row Splitting有什么区别？那两种技术在哪些方面有所不同？

我还读过这篇文章(数据库水平和垂直缩放之间的差异),水平分区和垂直分区之间的区别在于,您通过添加更多机器来扩展第一个,而在第二个中您通过添加更多功率进行扩展( CPU,RAM)到你现有的机器,是一个正确的定义？我认为这两种技术之间的核心区别在于您分割表格的方式.

对于大量问题我很抱歉,但是我有点困惑,因为我遇到的很多不同的网站都说不同的东西.

任何帮助澄清将不胜感激.任何带有几个表格的简单演示的链接也会非常有用.

以下两个查询组件的性能如何比较？

更喜欢

... LOWER(description) LIKE '%abcde%' ...

我喜欢

... description iLIKE '%abcde%' ...