标签 数据库 下的文章

Apache ShardingSphere 是一个开源的分布式数据库,它还有一个用户和开发人员需要的生态系统,为之提供了定制和云原生的体验。

 title=

Apache ShardingSphere 是一个开源的分布式数据库,它还有一个用户和开发人员需要的生态系统,为之提供了定制和云原生的体验。在加入 Apache 基金会的三年里,ShardingSphere 核心团队与社区一起努力工作,创建了一个开源的、强大的、分布式的数据库和一个支持性生态系统。

ShardingSphere 并不完全符合业界通常的简单分布式数据库中间件解决方案的模式。ShardingSphere 重新创建了分布式可插拔系统,使实际的用户实施方案得以蓬勃发展,并为社区和数据库行业贡献有价值的解决方案。

ShardingSphere 的目标是 Database Plus 概念。

Database Plus

Database Plus 的出发点是在零散的数据库基本服务之上建立一个标准层和生态系统层。统一的、标准化的数据库使用规范为上层应用提供了保障,尽可能的减少了企业因底层数据库碎片化而面临的挑战。为了连接数据库和应用,它使用了流量和数据的渲染和解析。它为用户提供了增强的核心功能,如分布式数据库、数据安全、数据库网关和压力测试。

ShardingSphere 为 Database Plus 使用了可插拔的内核架构。这意味着模块化,这为用户提供了灵活性。它有几个不同的层:

  • 基础层: 提供各种访问终端和访问形式,满足用户在不同场景下的需求。
  • 插件层: 通过实现可扩展性提供基础设施支持。
  • 功能层: 提供各种满足用户需求的功能插件,使用户在选择和组合插件时具有高度的灵活性。
  • 产品层: 这是终端用户看到的层。这为他们提供了面向行业和特定场景的产品。换句话说,它为用户提供了适合他们所做的任何工作的工具。

 title=

(Trista Pan, CC BY-SA 4.0

用 DistSQL 进行标准化的集群管理

Apache ShardingSphere 采用独特的 SQL 方言 DistSQL(分布式 SQL)来连接 ShardingSphere 生态系统的所有元素。作为 ShardingSphere 分布式数据库生态系统的标准交互语言,DistSQL 允许用户使用一个 SQL 命令来创建、修改或删除分布式数据库表或对其进行加密或解密。DistSQL 还支持分布式调度管理。

 title=

(Trista Pan, CC BY-SA 4.0

多访问终端

ShardingSphere JDBC 和 ShardingSphere Proxy 经过两年的打磨和测试,目前已经可以投入生产。许多社区用户提供了相关的生产社区案例。

多亏共享核心架构,以及不同的 ShardingSphere 适配器,如果用户的生产环境需要,可以选择混合适配器部署(如下图所示)。

 title=

(Trista Pan, CC BY-SA 4.0

分布式治理

在 ShardingSphere 生态系统中,计算和存储是分开的,因此具备对数据库进行分布式治理的能力,所以你可以维护许多存储节点、计算节点,实施断路器,并确保高可用性。

 title=

(Trista Pan, CC BY-SA 4.0

使用 Grafana 监控

ShardingSphere 也有状态指标来监控你的基础设施。代理动态加载机制为你提供了指标和跟踪指标,方便您将 APM 系统与 Grafana 仪表板集成。

 title=

(Trista Pan, CC BY-SA 4.0

分布式社区的分布式数据库

社区正在继续优化 ShardingSphere,并整合新的想法和行业场景。社区构建了它,而开发的主要动力之一是用户反馈。这是开源的一个特点,但也是这个团队的实践方法。ShardingSphere 社区的核心团队成员很乐意指导任何对开源感兴趣的人,并为有兴趣帮助开发的学生提供实践问题。团队也希望有新的朋友或贡献者加入社区,促进思想的开放交流,创造一个真正的全球开发者社区。


via: https://opensource.com/article/21/12/apache-shardingsphere

作者:Trista Pan 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

优化查询语句不过是一项简单的工程,而非什么高深的黑魔法。

 title=

许多人将数据库查询语句的调优视作哈利波特小说中某种神秘的“黑魔法”;使用错误的咒语,数据就会从宝贵的资源变成一堆糊状物。

实际上,对关系数据库系统的查询调优是一项简单的工程,其遵循的规则或启发式方法很容易理解。查询优化器会翻译你发送给 MySQL 实例的查询指令,然后将这些启发式方法和优化器已知的数据信息结合使用,确定获取所请求数据的最佳方式。再读一下后面这半句:“优化器已知的数据信息。”查询优化器需要对数据所在位置的猜测越少(即已知信息越多),它就可以越好地制定交付数据的计划。

为了让优化器更好地了解数据,你可以考虑使用索引和直方图。正确使用索引和直方图可以大大提高数据库查询的速度。这就像如果你按照食谱做菜,就可以得到你喜欢吃的东西;但是假如你随意在该食谱中添加材料,最终得到的东西可能就不那么尽如人意了。

基于成本的优化器

大多数现代关系型数据库使用 基于成本的优化器 cost-based optimizer 来确定如何从数据库中检索数据。该成本方案是基于尽可能减少非常耗费资源的磁盘读取过程。数据库服务器内的查询优化器代码会在得到数据时对这些数据的获取进行统计,并构建一个获取数据的历史模型。

但历史数据是可能会过时的。这就好像你去商店买你最喜欢的零食,然后突然发现零食涨价或者商店关门了。服务器的优化进程可能会根据旧信息做出错误的假设,进而制定出低效的查询计划。

查询的复杂性可能会影响优化。优化器希望提供可用的最低成本查询方式。连接五个不同的表就意味着有 5 的阶乘(即 120)种可能的连接组合。代码中内置了启发式方法,以尝试对所有可能的选项进行快捷评估。MySQL 每次看到查询时都希望生成一个新的查询计划,而其他数据库(例如 Oracle)则可以锁定查询计划。这就是向优化器提供有关数据的详细信息至关重要的原因。要想获得稳定的性能,在制定查询计划时为查询优化器提供最新信息确实很有效。

此外,优化器中内置的规则可能与数据的实际情况并不相符。没有更多有效信息的情况下,查询优化器会假设列中的所有数据均匀分布在所有行中。没有其他选择依据时,它会默认选择两个可能索引中较小的一个。虽然基于成本的优化器模型可以制定出很多好的决策,但最终查询计划并不是最佳方案的情况也是有可能的。

查询计划是什么?

查询计划 query plan 是指优化器基于查询语句产生的,提供给服务器执行的计划内容。查看查询计划的方法是在查询语句前加上 EXPLAIN 关键字。例如,以下查询要从城市表(city)和相应的国家表(country)中获得城市名称(和所属国家名称),城市表和国家表通过国家唯一代码连接。本例中仅查询了英国的字母顺序前五名的城市:

SELECT city.name AS 'City',
               country.name AS 'Country'
FROM city
JOIN country ON (city.countrycode = country.code)
WHERE country.code = 'GBR'
LIMIT 5;

在查询语句前加上 EXPLAIN 可以看到优化器生成的查询计划。跳过除输出末尾之外的所有内容,可以看到优化后的查询:

SELECT `world`.`city`.`Name` AS `City`,
                'United Kingdom' AS `Country`
FROM `world`.`city`
JOIN `world`.`country`
WHERE (`world`.`city`.`CountryCode` = 'GBR')
LIMIT 5;

看下比较大的几个变化, country.name as 'Country' 改成了 'United Kingdom' AS 'Country'WHERE 子句从在国家表中查找变成了在城市表中查找。优化器认为这两个改动会提供比原始查询更快的结果。

索引

在 MySQL 世界中,你会听到索引或键的概念。不过,索引是由键组成的,键是一种识别记录的方式,并且大概率是唯一的。如果将列设计为键,优化器可以搜索这些键的列表以找到所需的记录,而无需读取整个表。如果没有索引,服务器必须从第一列的第一行开始读取每一行数据。如果该列是作为唯一索引创建的,则服务器可以直接读取该行数据并忽略其余数据。索引的值(也称为基数)唯一性越强越好。请记住,我们在寻找更快获取数据的方法。

MySQL 默认的 InnoDB 存储引擎希望你的表有一个主键,并按照该键将你的数据存储在 B+ 树中。“不可见列”是 MySQL 最近添加的功能,除非在查询中明确指明该不可见列,否则不会返回该列数据。例如,SELECT * FROM foo; 就不会返回任何不可见列。这个功能提供了一种向旧表添加主键的方法,且无需为了包含该新列而重写所有查询语句。

更复杂的是,有多种类型的索引,例如函数索引、空间索引和复合索引。甚至在某些情况下,你还可以创建这样一个索引:该索引可以为查询提供所有请求的信息,从而无需再去访问数据表。

本文不会详细讲解各种索引类型,你只需将索引看作指向要查询的数据记录的快捷方式。你可以在一个或多个列或这些列的一部分上创建索引。我的医师系统就可以通过我姓氏的前三个字母和出生日期来查找我的记录。使用多列时要注意首选唯一性最强的字段,然后是第二强的字段,依此类推。“年-月-日”的索引可用于“年-月-日”、“年-月”和“年”搜索,但不适用于“日”、“月-日”或“年-日”搜索。考虑这些因素有助于你围绕如何使用数据这一出发点来设计索引。

直方图

直方图就是数据的分布形式。如果你将人名按其姓氏的字母顺序排序,就可以对姓氏以字母 A 到 F 开头的人放到一个“逻辑桶”中,然后将 G 到 J 开头的放到另一个中,依此类推。优化器会假定数据在列内均匀分布,但实际使用时多数情况并不是均匀的。

MySQL 提供两种类型的直方图:所有数据在桶中平均分配的等高型,以及单个值在单个桶中的等宽型。最多可以设置 1,024 个存储桶。数据存储桶数量的选择取决于许多因素,包括去重后的数值量、数据倾斜度以及需要的结果准确度。如果桶的数量超过某个阈值,桶机制带来的收益就会开始递减。

以下命令将在表 t 的列 c1 上创建 10 个桶的直方图:

ANALYZE TABLE t UPDATE HISTOGRAM ON c1 WITH 10 BUCKETS;

想象一下你在售卖小号、中号和大号袜子,每种尺寸的袜子都放在单独的储物箱中。如果你想找某个尺寸的袜子,就可以直接去对应尺寸的箱子里找。MySQL 自从三年前发布 MySQL 8.0 以来就有了直方图功能,但该功能却并没有像索引那样广为人知。与索引不同,使用直方图插入、更新或删除记录都不会产生额外开销。而如果更新索引,就必须更新 ANALYZE TABLE 命令。当数据变动不大并且频繁更改数据会降低效率时,直方图是一种很好的方法。

选择索引还是直方图?

对需要直接访问的且具备唯一性的数据项目使用索引。虽然修改、删除和插入操作会产生额外开销,但如果数据架构正确,索引就可以方便你快速访问。对不经常更新的数据则建议使用直方图,例如过去十几年的季度结果。

结语

本文源于最近在 Open Source 101 会议 上的一次报告。报告的演示文稿源自 PHP UK Conferenc 的研讨会。查询调优是一个复杂的话题,每次我就索引和直方图作报告时,我都会找到新的可改进点。但是每次报告反馈也表明很多软件界中的人并不精通索引,并且时常使用错误。我想直方图大概由于出现时间较短,还没有出现像索引这种使用错误的情况。


via: https://opensource.com/article/21/5/mysql-query-tuning

作者:Dave Stokes 选题:lujun9972 译者:unigeorge 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

使用数据库查询操作轻松获取系统信息。

 title=

Linux 提供了很多帮助用户收集主机操作系统信息的命令:列出文件或者目录的属性信息;查询安装的软件包、正在执行的命令、开机时启动的服务;或者了解系统的硬件。

每个命令使用自己的输出格式列出系统的信息。你需要使用 grepsedawk 这样的工具过滤命令输出的结果,以便找到特定的信息。此外,很多这样的信息会频繁变动,导致系统状态的改变。

将所有的信息格式化为一个数据库的 SQL 查询的输出进行查看将会十分有益。想象一下,你能够像查询具有类似名称的 SQL 数据库表一样查询 psrpm 命令的输出。

幸运的是,有一个工具刚好实现了这个功能,而且功能更多:Osquery 是一个 开源的 “由 SQL 驱动的操作系统仪表、监控和分析框架”。

许多处理安全、DevOps、合规性的应用,以及仓储管理管理(仅举几例)在内部依赖 Osquery 提供的核心功能。

安装 Osquery

Osquery 适用于 Linux、macOS、Windows、FreeBSD。请按照 指南 为你的操作系统安装最新版本。(我会在下面的例子中使用 4.7.0 版本。)

安装完成后,确保 Osquery 可以工作:

$ rpm -qa | grep osquery
osquery-4.7.0-1.linux.x86_64
$
$ osqueryi --version
osqueryi version 4.7.0
$

Osquery 组件

Osquery 有两个主要组件:

  • osqueri 是一个交互式的 SQL 查询控制台,可以独立运行,不需要超级用户权限(除非要查询的表格需要访问权限)。
  • osqueryd 像一个安装在主机的监控守护进程,可以定期调度查询操作执行,从底层架构收集信息。

可以在不运行 osqueryd 的情况下执行 osqueri。另一个工具,osqueryctl,控制守护进程的启动、停止,并检查其状态。

$ rpm -ql osquery-4.8.0-1.linux.x86_64 | grep bin
/usr/bin/osqueryctl
/usr/bin/osqueryd
/usr/bin/osqueryi
$

使用 osqueryi 交互式命令提示符

你和 Osquery 的交互与使用 SQL 数据库十分相似。事实上,osqueryi 是 SQList shell 的一个修改版。执行 osqueryi 命令进入交互式命令提示符 ,就可以执行 Osquery 的命令,通常以 . 开始:

$ osqueryi
Using a virtual database. Need help, type '.help'
osquery>

要退出交互式命令提示符,执行 .quit 命令回到操作系统的命令提示符:

osquery>
osquery> .quit
$

找出可用的表

如前所述,Osquery 像 SQL 查询一样输出数据,数据库中的信息通常保存在表中。但是如何在不知道表名的情况下查询这些表呢?你可以运行 .tables 命令列出所有可以查询的表。如果你是一个 Linux 长期用户或者一个系统管理员 ,就会对表名十分熟悉,因为你一直在使用操作系统命令获取同样的信息:

osquery> .tables
  => acpi_tables
  => apparmor_events
  => apparmor_profiles
  => apt_sources

<<裁剪>>

  => arp_cache
  => user_ssh_keys
  => users
  => yara
  => yara_events
  => ycloud_instance_metadata
  => yum_sources
osquery>

检查各个表的模式

知道表名后,可以查看每个表提供的信息。既然 ps 命令经常用于获取进程信息,就以 processes 为例。执行 .schema 命令加上表名查看表中保存的信息。如果要验证命令返回的结果,可以快速执行 ps -efps aux,对比命令的输出和表中的内容:

osquery> .schema processes
CREATE TABLE processes(`pid` BIGINT, `name` TEXT, `path` TEXT, `cmdline` TEXT, `state` TEXT, `cwd` TEXT, `root` TEXT, `uid` BIGINT, `gid` BIGINT, `euid` BIGINT, `egid` BIGINT, `suid` BIGINT, `sgid` BIGINT, `on_disk` INTEGER, `wired_size` BIGINT, `resident_size` BIGINT, `total_size` BIGINT, `user_time` BIGINT, `system_time` BIGINT, `disk_bytes_read` BIGINT, `disk_bytes_written` BIGINT, `start_time` BIGINT, `parent` BIGINT, `pgroup` BIGINT, `threads` INTEGER, `nice` INTEGER, `is_elevated_token` INTEGER HIDDEN, `elapsed_time` BIGINT HIDDEN, `handle_count` BIGINT HIDDEN, `percent_processor_time` BIGINT HIDDEN, `upid` BIGINT HIDDEN, `uppid` BIGINT HIDDEN, `cpu_type` INTEGER HIDDEN, `cpu_subtype` INTEGER HIDDEN, `phys_footprint` BIGINT HIDDEN, PRIMARY KEY (`pid`)) WITHOUT ROWID;
osquery>

要进一步确认,可以使用下面的命令查看 RPM 包的结构信息,然后与操作系统命令 rpm -qarpm -qi 的输出比较:

osquery>
osquery> .schema rpm_packages
CREATE TABLE rpm_packages(`name` TEXT, `version` TEXT, `release` TEXT, `source` TEXT, `size` BIGINT, `sha1` TEXT, `arch` TEXT, `epoch` INTEGER, `install_time` INTEGER, `vendor` TEXT, `package_group` TEXT, `pid_with_namespace` INTEGER HIDDEN, `mount_namespace_id` TEXT HIDDEN, PRIMARY KEY (`name`, `version`, `release`, `arch`, `epoch`, `pid_with_namespace`)) WITHOUT ROWID;
osquery>

从 Osquery 的 表格文档 获取更多信息。

使用 PRAGMA 命令

或许模式信息对你来说太难看懂,还有另一种途径能够以详细的表格格式打印表中的信息:PRAGMA 命令。例如,我想通过 PRAGMA 用一种易于理解的格式查看 rpm_packages 表的信息:

osquery> PRAGMA table_info(rpm_packages);

这种表格式信息的一个好处是你可以关注想要查询的字段,查看命令提供的类型信息:

osquery> PRAGMA table_info(users);
+-----+-------------+--------+---------+------------+----+
| cid | name        | type   | notnull | dflt_value | pk |
+-----+-------------+--------+---------+------------+----+
| 0   | uid         | BIGINT | 1       |            | 1  |
| 1   | gid         | BIGINT | 0       |            | 0  |
| 2   | uid_signed  | BIGINT | 0       |            | 0  |
| 3   | gid_signed  | BIGINT | 0       |            | 0  |
| 4   | username    | TEXT   | 1       |            | 2  |
| 5   | description | TEXT   | 0       |            | 0  |
| 6   | directory   | TEXT   | 0       |            | 0  |
| 7   | shell       | TEXT   | 0       |            | 0  |
| 8   | uuid        | TEXT   | 1       |            | 3  |
+-----+-------------+--------+---------+------------+----+
osquery>

进行你的第一次查询

在你从表、模式、条目中获取到所有进行查询所需要的信息后,进行你的第一次 SQL 查询查看其中的信息。下面的查询返回系统中的用户和每个用户的用户 ID、组 ID、主目录和默认的命令行解释器。Linux 用户通过查看 /etc/passwd 文件的内容并执行 grepsedawk 命令获取同样的信息。

osquery>
osquery> select uid,gid,directory,shell,uuid FROM users LIMIT 7;
+-----+-----+----------------+----------------+------+
| uid | gid | directory      | shell          | uuid |
+-----+-----+----------------+----------------+------+
| 0   | 0   | /root          | /bin/bash      |      |
| 1   | 1   | /bin           | /sbin/nologin  |      |
| 2   | 2   | /sbin          | /sbin/nologin  |      |
| 3   | 4   | /var/adm       | /sbin/nologin  |      |
| 4   | 7   | /var/spool/lpd | /sbin/nologin  |      |
| 5   | 0   | /sbin          | /bin/sync      |      |
| 6   | 0   | /sbin          | /sbin/shutdown |      |
+-----+-----+----------------+----------------+------+
osquery>

不进入交互模式的查询

如果你想要在不进入 osqueri 交互模式的情况下进行查询,该怎么办?要用查询操作写命令行解释器脚本,这种方式可能十分有用。这种情况下,可以直接从 Bash 解释器 echo SQL 查询,通过管道输出到 osqueri

$ echo "select uid,gid,directory,shell,uuid FROM users LIMIT 7;" | osqueryi
+-----+-----+----------------+----------------+------+
| uid | gid | directory      | shell          | uuid |
+-----+-----+----------------+----------------+------+
| 0   | 0   | /root          | /bin/bash      |      |
| 1   | 1   | /bin           | /sbin/nologin  |      |
| 2   | 2   | /sbin          | /sbin/nologin  |      |
| 3   | 4   | /var/adm       | /sbin/nologin  |      |
| 4   | 7   | /var/spool/lpd | /sbin/nologin  |      |
| 5   | 0   | /sbin          | /bin/sync      |      |
| 6   | 0   | /sbin          | /sbin/shutdown |      |
+-----+-----+----------------+----------------+------+
$

获悉系统启动时开始的服务

Osquery 还可以列出系统启动时开始的所有服务。例如,可以查询 startup_items 表获取启动时开始的前五项服务的名称、状态和路径:

osquery> SELECT name,type,status,path FROM startup_items LIMIT 5;
  name = README
  type = Startup Item
status = enabled
  path = /etc/rc.d/init.d/README

  name = anamon
  type = Startup Item
status = enabled
  path = /etc/rc.d/init.d/anamon

  name = functions
  type = Startup Item
status = enabled
  path = /etc/rc.d/init.d/functions

  name = osqueryd
  type = Startup Item
status = enabled
  path = /etc/rc.d/init.d/osqueryd

  name = AT-SPI D-Bus Bus
  type = Startup Item
status = enabled
  path = /usr/libexec/at-spi-bus-launcher --launch-immediately
osquery>

查阅二进制文件的 ELF 信息

假如你想要弄清 ls 二进制文件的更多细节,通常会通过 readelf -h 命令,加上 ls 命令的路径。查询 Osquery 的 elf_info 表你可以得到同样的信息:

osquery> SELECT * FROM elf_info WHERE path="/bin/ls";
      class = 64
        abi = sysv
abi_version = 0
       type = dyn
    machine = 62
    version = 1
      entry = 24064
      flags = 0
       path = /bin/ls
osquery>

现在你应该初步了解如何使用 osqueri 查询自己想要的信息。然而,这些信息保存在数量巨大的表中;我查询过的一个系统中,有 156 个不同的表,这个数字可能是十分惊人的:

$ echo ".tables" | osqueryi | wc -l
156
$

要让事情变得更容易,可以从这些表开始获取你的 Linux 系统的信息:

系统信息表:

osquery> select * from system_info;

系统限制信息:

osquery> select * from ulimit_info;

由各种进程打开的文件:

osquery> select * from process_open_files;

系统上开放的端口:

osquery> select * from listening_ports;

运行中的进程信息:

osquery> select * from processes;

已安装的包信息:

osquery> select * from rpm_packages;

用户登录信息:

osquery> select * from last;

系统日志信息:

osquery> select * from syslog_events;

了解更多

Osquery 是一个强大的工具,提供了许多可以用于解决各种使用案例的主机信息。你可以阅读 文档 了解更多 Osquery 的信息。


via: https://opensource.com/article/21/6/osquery-linux

作者:Gaurav Kamathe 选题:lujun9972 译者:YungeG 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Neo4j:数据库历史上最大的投资

图形数据库供应商 Neo4j 的 CEO 在该公司的年度虚拟会议上宣布了这笔 3.25 亿美元的 F 轮融资,使 Neo4j 的估值超过 20 亿美元。谷歌的母公司参与了投资,这是迄今为止对一家私营数据库公司的最大投资。

在会议上,Neo4j 还演示了一个有史以来最大的有 30 亿人的社交网络,展示了在 1000 多台机器上运行的拥有超过 2000 亿个节点和超过一万亿个关系的图的实时查询性能。

20 年前只有少数几个关系型数据库,而如今各种新式数据库层出不穷,市场规模也急剧扩大。

软件已经成为了汽车不可缺少的一部分

10 年前仅有高档车才会使用 100 个基于微处理器的微控制单元(ECU),运行大约一亿行代码。今天像宝马 7 系这类配备先进辅助驾驶系统的高档汽车可能使用了 150 个以上的 ECU,福特皮卡 F-150 运行的代码行数高达 150 亿。甚至低端汽车使用的 ECU 都接近 100 个,代码行数在 1 亿以上。

在完全自动驾驶来到之前,软件就开始吞噬汽车了。

数据中心加剧了干旱

报道,典型的数据中心每天使用约 1000-2000 万升的水,与一个拥有 3 万 - 5 万人口的城市的用水量相同。而每天都在建造更多的数据中心,其中近 40% 在美国,亚马逊、谷歌和微软占总数的一半以上。许多数据中心运营商被吸引到美国西部缺水的地区,部分原因是太阳能和风能的可用性。据估计,五分之一的数据中心从中度至高度紧张的流域取水。

虽然这是美国的情况,但是其它国家也纷纷在偏远干旱地区建设数据中心。

Exadata X8M 是第一台具有集成持久内存和 RoCE 的数据库机器。Oracle 还宣布推出 Oracle 零数据丢失恢复设备 X8M(ZDLRA)。

Oracle 发布了新的 Exadata 数据库机器 X8M,旨在为数据库基础架构市场树立新的标杆。

Exadata X8M 结合了英特尔 Optane DC 持久存储器和通过融合以太网(RoCE)的 100 千兆的远程直接内存访问(RDMA)来消除存储瓶颈,并显著提高性能,其适用于最苛刻的工作负载,如在线事务处理(OLTP)、分析、物联网、欺诈检测和高频交易。

“借助 Exadata X8M,我们可以提供内存级的性能,同时为 OLTP 和分析提供共享存储的所有优势,”Oracle 任务关键型数据库技术执行副总裁 Juan Loaiza 说。

“使用对共享持久存储器的直接数据库访问将响应时间减少一个数量级,可加速每个 OLTP 应用程序,它是需要实时访问大量数据的应用程序的游戏规则改变者,例如欺诈检测和个性化购物,”官方补充。

它有什么独特之处?

Oracle Exadata X8M 使用 RDMA 让数据库直接访问智能存储服务器中的持久内存,从而绕过整个操作系统、IO 和网络软件堆栈。这导致更低的延迟和更高的吞吐量。使用 RDMA 绕过软件堆栈还可以释放存储服务器上的 CPU 资源,以执行更多智能扫描查询来支持分析工作负载。

更少的存储瓶颈

“高性能 OLTP 应用需要高的每秒输入/输出操作(IOPS)和低延迟。直接数据库访问共享持久性内存可将SQL 读取的峰值性能提升至 1600 万 IOPS,比行业领先的 Exadata X8 高出 2.5 倍,“Oracle 在一份声明中表示。

此外,Exadata X8M 通过使远程 IO 延迟低于 19 微秒,大大减少了关键数据库 IO 的延迟 —— 这比 Exadata X8 快 10 倍以上。即使对于每秒需要数百万 IO 的工作负载,也可实现这些超低延迟。

比 AWS 和 Azure 更高效

该公司声称,与 Oracle 最快的 Amazon RDS 存储相比,Exadata X8M 的延迟降低了 50 倍,IOPS 提高了 200 倍,容量提高了 15 倍。

与 Azure SQL 数据库服务存储相比,Exadata X8M 的延迟降低了 100 倍,IOPS 提高了 150 倍,容量提高了 300 倍。

据 Oracle 称,单机架 Exadata X8M 可提供高达 2 倍的 OLTP 读取 IOPS,3 倍的吞吐量和比具有持久性内存的共享存储系统(如 Dell EMC PowerMax 8000 的单机架)低 5 倍的延迟。

“通过同时支持更快的 OLTP 查询和更高的分析工作负载吞吐量,Exadata X8M 是融合混合工作负载环境以降低 IT 成本和复杂性的理想平台,”该公司说。

Oracle 零数据丢失恢复设备 X8

Oracle 当天还宣布推出 Oracle 零数据丢失恢复设备 X8M(ZDLRA),它使用新的 100Gb RoCE,用于计算和存储服务器之间的高吞吐量内部数据传输。

Exadata 和 ZDLRA 客户现在可以在 RoCE 或基于 InfiniBand 的工程系统之间进行选择,以在其架构部署中实现最佳灵活性。


via: https://opensourceforu.com/2019/09/oracle-unleashes-worlds-fastest-database-machine-exadata-x8m/

作者:Longjam Dineshwori 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

了解如何选择最适合你的需求的开源数据库。

在现代的企业级技术领域中,开源软件已经成为了一股不可忽视的重要力量。借助 开源运动 open source movement 的东风,涌现除了许多重大的技术突破。

个中原因显而易见,尽管一些基于 Linux 的开源网络标准可能不如专有厂商的那么受欢迎,但是不同制造商的智能设备之间能够互相通信,开源技术功不可没。当然也有不少人认为开源开发出来的应用比厂商提供的产品更加好,所以无论如何,使用开源数据库进行开发确实是相当有利的。

和其它类型的应用软件一样,不同的开源数据库管理系统之间在功能和特性上可能会存在着比较大的差异。换言之,不是所有的开源数据库都是平等的。因此,如果要为整个组织选择一个开源数据库,那么应该重点考察数据库是否对用户友好、是否能够持续适应团队需求、是否能够提供足够安全的功能等方面的因素。

出于这方面考虑,我们在这篇文章中对一些开源数据库进行了概述和优缺点对比。遗憾的是,我们必须忽略一些最常用的数据库。值得注意的是,MongoDB 最近更改了它的许可证,因此它已经不是真正的开源产品了。从商业角度来看,这个决定是很有意义的,因为 MongoDB 已经成为了数据库托管实际上的解决方案,约 27000 家公司在使用它,但这也意味着 MongoDB 已经不再被视为真正的开源产品。

另外,自从 MySQL 被 Oracle 收购之后,这个产品就已经不再具有开源性质了,MySQL 可以说是数十年来首选的开源数据库。然而,这为其它真正的开源数据库解决方案提供了挑战它的空间。

下面是三个值得考虑的开源数据库。

PostgreSQL

没有 PostgreSQL 的开源数据库清单肯定是不完整的。PostgreSQL 一直都是各种规模企业的首选解决方案。Oracle 对 MySQL 的收购在当时来说可能具有一定的商业意义,但是随着云存储的日益壮大,开发者对 MySQL 的依赖程度或许并不如以前那么大了

尽管 PostgreSQL 不是一个最近几年才面世的新产品,但它却是借助了 MySQL 相对衰落的机会才逐渐成为最受欢迎的开源数据库之一。由于它和 MySQL 的工作方式非常相似,因此很多热衷于使用开源软件的开发者都纷纷转向 PostgreSQL。

优势

  • 目前 PostgreSQL 最显著的优点是它的核心算法的效率,这意味着它的性能优于许多宣称更先进数据库。这一点在处理大型数据集的时候就可以很明显地体现出来了,否则 I/O 处理会成为瓶颈。
  • PostgreSQL 也是最灵活的开源数据库之一,使用 Python、Perl、Java、Ruby、C 或者 R 都能够很方便地调用数据库。
  • 作为最常用的几个开源数据库之中,PostgreSQL 的社区支持是做得最好的。

劣势

  • 在数据量比较大的时候,PostgreSQL 的效率毋庸置疑是很高的,但对于数据量较小的情况,使用 PostgreSQL 就显得不如其它的一些工具快了。
  • 尽管拥有一个很优秀的社区支持,但 PostgreSQL 的核心文档仍然需要作出改进。
  • 如果你需要使用并行计算或者集群化等高级工具,就需要安装 PostgreSQL 的第三方插件。尽管官方有计划将这些功能逐步添加到主要版本当中,但可能会需要再等待好几年才能出现在标准版本中。

MariaDB

MariaDB 是 MySQL 的真正开源的发行版本(在 GNU GPLv2 下发布)。在 Oracle 收购 MySQL 之后,MySQL 的一些核心开发人员认为 Oracle 会破坏 MySQL 的开源理念,因此建立了 MariaDB 这个独立的分支。

MariaDB 在开发过程中替换了 MySQL 的几个关键组件,但仍然尽可能地保持兼容 MySQL。MariaDB 使用了 Aria 作为存储引擎,这个存储引擎既可以作为事务式引擎,也可以作为非事务式引擎。在 MariaDB 分叉出来之前,就有一些人推测 Aria 会成为 MySQL 未来版本中的标准引擎。

优势

  • 由于 MariaDB 频繁进行安全发布,很多用户选择使用 MariaDB 而不选择 MySQL。尽管这不一定代表 MariaDB 会比 MySQL 更加安全,但确实表明它的开发社区对安全性十分重视。
  • 有一些人认为,MariaDB 的主要优点就是它在坚持开源的同时会与 MySQL 保持高度兼容,这就意味着从 MySQL 向 MariaDB 的迁移会非常容易。
  • 也正是由于这种兼容性,MariaDB 也可以和其它常用于 MySQL 的语言配合使用,因此从 MySQL 迁移到 MariaDB 之后,学习和调试代码的时间成本会非常低。
  • 你可以将 WordPress 和 MariaDB(而不是 MySQL)配合使用从而获得更好的性能和更丰富的功能。WordPress 是最受欢迎的 内容管理系统 Content Management System (CMS),占据了一半的互联网份额,并且拥有活跃的开源开发者社区。各种第三方插件在 WordPress 和 MariaDB 配合使用时都能够正常工作。

劣势

  • MariaDB 有时会变得比较臃肿,尤其是它的 IDX 日志文件在长期使用之后会变得非常大,最终导致性能下降。
  • 缓存是 MariaDB 的另一个工作领域,并没有期望中那么快,这可能会让人有所失望。
  • 尽管 MariaDB 最初承诺兼容 MySQL,但目前 MariaDB 已经不是完全兼容 MySQL。如果要从 MySQL 迁移到 MariaDB,就需要额外做一些兼容工作。

SQLite

SQLite 可以说是世界上实现最多的数据库引擎,因为它被很多流行的 web 浏览器、操作系统和手机所采用。它最初是作为 MySQL 的轻量级分支所开发的。SQLite 和很多其它的数据库不同,它不采用客户端-服务端的引擎架构,而是将整个软件嵌入到每个实现当中。

这样的架构让 SQLite 拥有一个强大的优势,就是在嵌入式系统或者分布式系统中,每台机器都搭载了数据库的整个实现。这样的做法减少了系统间的调用,从而大大提高了数据库的性能。

优势

  • 如果你需要构建和实现一个小型数据库,SQLite 可能是最好的选择。它小而灵活,不需要费工夫寻求各种变通方案,就可以在嵌入式系统中实现。
  • SQLite 体积很小,因此速度极快。其它的一些高级数据库可能会使用复杂的优化方式来提高效率,但SQLite 采用了一种更简单的方法:通过减小数据库及其处理软件的大小,以使处理的数据更少。
  • SQLite 被广泛采用也导致它可能是兼容性最高的数据库。如果你希望将应用程序集成到智能手机上,这一点尤为重要:只要是可以工作于广泛环境中的第三方应用程序,就可以原生运行于 iOS 上。

劣势

  • SQLite 的体积小意味着它缺少了很多其它大型数据库的常见功能。例如数据加密就是抵御黑客攻击的标准功能,而 SQLite 却没有内置这个功能。
  • SQLite 的广泛流行和源码公开使它易于使用,但是也让它更容易遭受攻击。这是它最大的劣势。SQLite 经常被发现高危的漏洞,例如最近的 Magellan
  • 尽管 SQLite 单文件的方式拥有速度上的优势,但是要使用它实现多用户环境却比较困难。

哪个开源数据库才是最好的?

当然,对于开源数据库的选择还是取决于业务的需求,尤其是系统的体量。对于小型数据库或者是使用量比较小的数据库,可以使用比较轻量级的解决方案,这样不仅可以加快实现的速度,而且由于系统的复杂程度不算太高,花在调试上的时间成本也不会太高。

而对于大型的系统,尤其是在成长性企业中,最好还是花时间使用更复杂的数据库(例如 PostgreSQL)。这是一个磨刀不误砍柴工的选择,能够让你不至于在后期再重新选择另一款数据库。


via: https://opensource.com/article/19/1/open-source-databases

作者:Sam Bocetta 选题:lujun9972 译者:HankChow 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出