标签: database-performance

决定使用哪个数据库？有什么比较吗？

• 现有：postgresql
• 问题
  • 不容易横向扩展。需要分片等
  • 聚类不能解决数据增长问题
• 寻找：任何易于水平扩展的数据库
  • Cassandra（Twitter 使用那个？）
  • MongoDB（迅速普及）
  • 伏地魔
  • 其他？
• 为什么？
  • 数据随着滚雪球效应增长
  • 现有的 postgresql 定期锁定表等以用于 vaccuum 任务
  • 目前归档数据很潮
  • 现有档案、真空、……过程中定期进行的人工交互
  • 需要一个'设置它。算了吧。只需在数据增长更多时添加另一台服务器。解决方案类型

我正在尝试通过一些 Mongo 日志进行 grep 以尝试找到我需要优化的缓慢操作。慢查询日志记录是默认的，记录操作超过 100 毫秒。

我认为可以肯定地说，一般来说，搜索 COLLSCANS 会显示需要注意的查询。不太清楚的是，如果 IXSCANS 是我应该搜索的细节。

考虑此处的 MongoDB 文档：

https://docs.mongodb.com/manual/reference/explain-results/#collection-scan-vs-index-use

我的理解是这是一种二元情况，查询是 COLLSCAN 或 IXSCAN。因此，如果我对 IXSCAN 进行 grep，我将查看所有不是 COLLSCANS 的慢查询。这是真的？

题

我怎样才能使这篇文章中描述的查询更快，特别是通过使用可用的 RAM 来创建 PostgreSQL？- 请注意，我已尝试适当地配置 Effective_cache_size 和 shared_buffers。见下文。

背景

我必须定期将大约 2.6 亿行表 (coreg_master) 加入进来的新数据。我已经对表进行了分区，以允许每个分区都适合 RAM。当然，我也设置了适当的索引。但是，当将分区表与其他（小得多）表分开连接时，它会在磁盘上进行完全随机的 IO。这是由于对大表的嵌套循环索引扫描造成的，这真的很慢，因为我们没有很好的磁盘设置。

我希望它使用所有可用的 RAM 来缓存大型分区表，我认为这应该由 Linux 内核/文件系统本身完成。但是它仍然不会将表加载到 RAM 中，尽管它适合。我猜这是因为访问模式不是顺序的，因此不会触发缓存？我不知道。查询计划和配置参数如下。

表结构

这是coreg_master的分区之一，我的大表。分区表被命名为 coreg_a、coreg_b 等。

\d coreg_a
                                   Table "public.coreg_a"
   Column    |       Type        |                         Modifiers                         
-------------+-------------------+-----------------------------------------------------------
 id          | integer           | not null default nextval('coreg_master_id_seq'::regclass)
 first_name  | character varying | 
 last_name   | character varying | 
 phone       | character varying | 
 city        | character varying | 
 zip         | integer           | 
 address     | character varying | 
 dob         | date              | …

在搜索和阅读了尽可能多的帖子、评论和讨论后，我发现我没有找到一个特定于我的问题的帖子。

我在同一个交付区域 us-west-2(c) 中有多个带有单个 RDS 的 AWS EC2 部署

我正在测试实例的负载，只是我很快就会期待的一小部分。我关心的问题是推送更新时的性能。我们将频繁地一次获取 1,000 条记录的更新，并将获取和比较我们的数据并酌情更新我们的数据。因此，每个条目一次读取和一次写入。一个小时内收到 100,000 条更新的情况并不少见。

目前，我在 AWS t2.medium 类 RDS 上有一个 MySQL 数据库，它在 22% 的 CPU 和小于 1GB 的内存下运行 5 个更新进程。

即使使用这些低数字，搜索 106.3K 记录的数据库的读取时间也需要 2 到 3 秒，而写入时间是另外 2 秒。

我需要一些关于如何改善这些读/写时间的想法。

附加信息：我还有一个副本实例正在运行。CMS 驱动的站点（100 个并且每天增长）连接到其内容的副本实例。

谢谢！

我正在尝试通过复制命令将大约 100M 记录（磁盘上大约 8GB）的 CSV 加载到 Postgres ：copy mytable from 'path/to/myfile.csv' with CSV;我一直在通过检查 pgAdmin 中报告的表大小并将其与 CSV 大小进行比较来监视进度。我知道这充其量只是一个松散的比较，我很想知道是否有更好的方法来监控进度。

问题是：这个加载已经持续了很长时间（我认为太长了），当我不断检查表大小时，加载似乎正在减速。也就是说，现在加载新的 100MB 数据所需的时间比之前加载的时间长得多。为什么？

除了将我的 CSV 分解成许多较小的文件之外，是否有任何调整、配置或替代方法可以加快加载速度？

更新：架构/数据细节

一个有代表性的数据行：

1234567890,FOOBARF,2010-01-15 03:07:05,0.924700,0.925000

完整的架构定义：

CREATE TABLE mytable
(
  id integer NOT NULL,
  rname character varying(7) NOT NULL,
  ts timestamp without time zone NOT NULL,
  stat1 numeric NOT NULL,
  stat2 numeric NOT NULL,
  CONSTRAINT pk_id PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE mytable OWNER TO postgres;

我们正在构建一个应用程序，其中每个客户端都有自己的数据库。没有一个数据库特别大（每个 20MB 到 400MB），但将有大约 5,000 个要启动，并且在任何时候都会有 100 个左右处于活动状态。

我们的团队一直在讨论如何最好地设置系统。客户每 2 周只访问一次他们的数据库（401k/财务处理），并且一次只使用 10-30 分钟。操作在读/写之间均匀分布。

我们团队中有一半人认为因此我们应该将数据库分布在多个便宜的服务器上并只使用 SQL Express ...他们说内存/缓存不会那么有用，因为每个数据库的使用时间都很短（我们在 1 台以上的服务器上没有完整 SQL 标准的预算）。

是这种情况吗？更高的内存限制确实是我看到 MSSQL Standard 给我们带来的唯一优势（我们已经有了用于执行备份/恢复、架构升级、迁移数据等的脚本）。

更新

我对多个数据库与一个数据库的性能特征特别感兴趣。使用单个 200MB 数据库的最终用户体验会不会比使用 1TB 数据库更好（即使两者都编入了良好的索引）？这也意味着我们可以非常快速地轻松备份/恢复单个客户端数据库，对吗？我们是否需要调整 SQL Server 以更好地处理“数千个数据库”的情况？

我在谷歌上做了一些阅读，我做的唯一一件事就是让自己感到困惑。有些人说 count() 有很多记录会比较慢，其他人说你可以缓存数字甚至使用序列......

在具有最佳性能和最低 cpu/ram 使用率的表中计算多行的最佳方法是什么？许多我的意思是 >=500,000 行。

我正在设置具有以下规格的服务器：
* 4 个处理器（每个具有 12 个内核的 AMD Opterons）
* 32 GB 内存
* 8 个 HDD（15K SAS 双端口）
* CentOS 5.5
* JBoss
* PostgreSQL

稍后我可能会将应用程序与数据库分开，但现在它们将在同一台机器上。我已经读到 PostgreSQL 性能受益于：
* RAID 10
* 单独的操作系统分区
* 单独的 xlog 分区
* 单独的 pgdata 分区

由于我的单个 RAID 10 卷似乎总共有 559808 MB 可用，这是当前的分区计划：
* 337856 MB 用于操作系统
* 102400 MB 用于 pgdata
* 51200 MB 用于 xlog
* 68352 MB 用于交换

以下是一些问题：
* 我的分区计划看起来如何？
* 在安装 CentOS 时，当我进入磁盘设置步骤时，我需要定义挂载点 - 我应该为 pgdata 分区输入什么？（例如，参考此示例设置挂载点 /pgdata1） …

我们有一个 LAMP 盒，带有 2 个镜像的 1 TB WD Black Caviar 磁盘，运行整个操作系统和 MySQL。8 GB / RAM，2 个四核 CPU。

我们真的对磁盘 I/O 负担过重，我一直在考虑建议在那里安装几个 SSD 驱动器/var/lib/mysql，然后完成它。我做了一些研究，我喜欢 Intel X25-M 160 GB 的价格点，但我已经阅读了有关生产中 SSD 的相互矛盾的选项。

我们大约有 70 GB，主要是 MyISAM 表（> 95%）。我们主要在生产期间（晚上 8 点到 5 点）进行读取，主要是在夜间（上午 12 点到早上 8 点）写入。

之前有一些关于生产中的 SSD 的有用帖子，但我认为更好的帖子有点过时了（最好的帖子是 2008 年）。是否有更多关于 SSD 是否真的为中型企业做好准备的最新反馈？如果没有，我怎样才能更好地扩展我们的数据库服务器？

我们正在开发的系统由一个 Web 应用程序前端和一个使用 SQL Server 2008 R2 中的存储过程进行大量数据处理的后端组成（请不要问为什么...）。这些存储过程大量使用临时表（创建、插入、连接），因此tempdb 的I/O 率在写入和读取中很高。我们的客户需要速度，因此我们将推荐以下内容：

• 购买带有 RAID 1 SSD 阵列的服务器来存储主数据库（如果他们有钱，可能是 RAID10），使用另一个硬盘驱动器安装操作系统和 SQL Server，以便将重要数据与复制一起存储在快速驱动器中，以及64 GB 内存。
• 使用 Ramdisk 存储tempdb数据库，因此临时表（我们认为最大的性能瓶颈）在 RAM 中处理。

一些上下文数据：

• 我们的数据库使用不超过 10 GB，预期增长率非常低。Tempdb 通常增长到不超过 2-3 GB。
• 服务器将用于 DB 和 Web 服务器。
• Ramdisk 软件可以在 windows 启动时挂载 ramdisk。

我们已经在具有大量内存的笔记本电脑中测试了 ramdisk 方法。至少，加速是显着的（存储过程执行时间减少到 1/3）。

我需要帮助来确定这是否是一个好的解决方案，并检测我可能遗漏的任何缺陷（明显的或不太明显的）。

编辑：感谢您到目前为止的答案！我忘了明确提到将有并发用户使用该应用程序，因此将有多个临时表操作正在运行。此外，混合 Web 服务器和数据库服务器不是我们的选择，我们已经知道这不是最佳的 ;)