SQLite的性能和限制

Performance and Limitations
SQLite is a speedy database. But the words speedy, fast, peppy, or quick are rather subjective terms. To be
perfectly honest, there are things SQLite can do faster than other databases, and there are things that it
cannot. Suffice it to say, within the parameters for which it has been designed, SQLite can be said to be
consistently fast and efficient across the board. SQLite uses B-trees for indexes and B+-trees for tables,
the same as most other database systems. For searching a single table, it is as fast if not faster than any
other database on average. Simple SELECT, INSERT, and UPDATE statements are extremely quick—virtually
at the speed of RAM (for in-memory databases) or disk. Here SQLite is often faster than other databases,
because it has less overhead to deal with in starting a transaction or generating a query plan and because
it doesn’t incur the overhead of making a network calls to the server or negotiating authentication and
privileges. Its simplicity here makes it fast.
As queries become larger and more complex, however, query time overshadows the network call or
transaction overhead, and the game goes to the database with the best optimizer. This is where larger,
more sophisticated databases begin to shine. While SQLite can certainly do complex queries, it does not
have a sophisticated optimizer or query planner. You can always trust SQLite to give you the result, but
what it won’t do is try to determine optimal paths by computing millions of alternative query plans and
selecting the fastest candidate, as you might expect from Oracle or PostgreSQL. Thus, if you are running
complex queries on large data sets, odds are that SQLite is not going to be as fast as databases with
sophisticated optimizers.
So, there are situations where SQLite is not as fast as larger databases. But many if not all of these
conditions are to be expected. SQLite is an embedded database designed for small to medium-sized
applications. These limitations are in line with its intended purpose. Many new users make the mistake
of assuming that they can use SQLite as a drop-in replacement for larger relational databases.
Sometimes you can; sometimes you can’t. It all depends on what you are trying to do.
In general, there are two major variables that define SQLite’s main limitations:
•Concurrency(并发). SQLite has coarse-grained locking, which allows multiple readers
but only one writer at a time. Writers exclusively lock the database during writes,
and no one else has access during that time. SQLite does take steps to minimize
the amount of time in which exclusive locks are held. Generally, locks in SQLite
are kept for only a few milliseconds. But as a general rule of thumb, if your
application has high write concurrency (many connections competing to write to
the same database) and it is time critical, you probably need another database. It
is really a matter of testing your application to know what kind of performance
you can get. We have seen SQLite handle more than 500 transactions per second
for 100 concurrent connections in simple web applications. But your transactions
may differ in the number of records being modified or the number and complexity
of the queries involved. Acceptable concurrency all depends on your particular
application and can be determined empirically only by direct testing. In general,
this is true with any database: you don’t know what kind of performance your
application will get until you do real-world tests.
•Networking(网络). Although SQLite databases can be shared over network file systems,
the latency associated with such file systems can cause performance to suffer.
Worse, bugs in network file system implementations can also make opening and
modifying remote files—SQLite or otherwise—error prone. If the file system’s
locking does not work properly, two clients may be allowed to simultaneously
modify the same database file, which will almost certainly result in database
corruption. It is not that SQLite is incapable of working over a network file system
because of anything in its implementation. Rather, SQLite is at the mercy of the
underlying file system and wire protocol, and those technologies are not always
perfect. For instance, many versions of NFS have a flawed fcntl()
implementation, meaning that locking does not behave as intended. Newer NFS
versions, such are Solaris NFS v4, work just fine and reliably implement the
requisite locking mechanisms needed by SQLite. However, the SQLite developers
have neither the time nor the resources to certify that any given network file
system works flawlessly in all cases.

 

Again, most of these limitations are intentional, resulting from SQLite’s design. Supporting high

write concurrency, for example, brings with it great deal of complexity, and this runs counter to SQLite’s
simplicity in design. Similarly, being an embedded database, SQLite intentionally does not support
networking. This should come as no surprise. In short, what SQLite can’t do is a direct result of what it
can. It was designed to operate as a modular, simple, compact, and easy-to-use embedded relational

database whose code base is within the reach of the programmers using it. And in many respects, it can

do what many other databases cannot, such as run in embedded environments where actual power
consumption is a limiting factor.
While SQLite’s SQL implementation is quite good, there are some things it currently does not
implement. These are as follows:
• Complete trigger support. SQLite supports almost all the standard features for
triggers, including recursive triggers and INSTEAD OF triggers. However, for all
trigger types, SQLite currently requires FOR EACH ROW behavior, where the triggered
action is evaluated for every row affected by the triggering query. ANSI SQL 92 also
describes a FOR EACH STATEMENT trigger style, which is not currently supported.
• Complete ALTER TABLE support. Only the RENAME TABLE and ADD COLUMN variants
of the ALTER TABLE command are supported. Other kinds of ALTER TABLE
operations such as DROP COLUMN, ALTER COLUMN, and ADD CONSTRAINT are not
implemented.
• RIGHT and FULL OUTER JOIN. LEFT OUTER JOIN is implemented, but RIGHT
OUTER JOIN and FULL OUTER JOIN are not. Every RIGHT OUTER JOIN has a provably
semantically identical LEFT OUTER JOIN, and vice versa. Any RIGHT OUT JOIN can be
implemented as a LEFT OUTER JOIN by simply reversing the order of the tables and
modifying the join constraint. A FULL OUTER JOIN can be implemented as a
combination of two LEFT OUTER JOIN statements, a UNION, and appropriate NULL
filtering in the WHERE clause.
• Updatable views. Views in SQLite are read-only. You may not execute a DELETE,
INSERT, or UPDATE statement on a view. But you can create a trigger that fires on an
attempt to DELETE, INSERT, or UPDATE a view and do what you need in the body of
the trigger.

• Windowing functions. One of the new feature sets specified in ANSI SQL 99 are
the windowing functions. These provide post-processing analytic functions for
results, such a ranking, rolling averages, lag and lead calculation, and so on.
SQLite currently only targets ANSI SQL 92 compliance, so it doesn’t support
windowing functions like RANK(), ROW_NUMBER(), and so on.
• GRANT and REVOKE. Since SQLite reads and writes an ordinary disk file, the only
access permissions that can be applied are the normal file access permissions of
the underlying operating system. GRANT and REVOKE commands in general are
aimed at much higher-end systems where there are multiple users who have
varying access levels to data in the database. In the SQLite model, the application
is the main user and has access to the entire database. Access in this model is
defined at the application level—specifically, what applications have access to the
database file.
In addition to what is listed here, there is a page on the SQLite wiki devoted to reporting
unsupported SQL. It is located at www.sqlite.org/cvstrac/wiki?p=UnsupportedSql.

 

From: The Definitive Guide to SQLite (2nd edition)

译文:https://blog.csdn.net/yuzhouxiang/article/details/7373111

性能和限制

SQLite是一个很快的数据库,但"快"这个词本身是一个主观的和模糊不清的词。坦白地讲,对于有些事情,SQLite比其他数据库做得快,也有些事情比不上其他数据库。利用SQLite提供的配置参数,SQLite是足够快速和高效的。与大多数数据库一样,SQLite使用B-tree做索引,使用B+-tree处理表。因此,在对单表进行查询时,平均而言,SQLite与其他数据库一样快(至少不慢于)。简单的SELECT、INSERT和UPDATE语句是相当快速的--几乎与内存(如果是内存数据库)或者磁盘同速。SQLite通常要快于其他数据库,因为它在处理一个事务开始,或者一个查询计划的产生方面开销较小,并且没有调用服务器的网络或认证以及权限协商的开销。它的简单性使它更快。

但是随着查询变大变复杂,查询时间使得网络调用或者事务处理开销相形见绌,SQLite将会与其他数据库一样。这时一些大型的设计复杂的数据库开始发挥作用了。虽然SQLite也能处理复杂的查询,但是它没有精密的优化器或者查询计划器。SQLite知道如何使用索引,但是它没有保存详细的表统计信息。假如执行17路join,SQLite也会连接表并给您结果,并不像您在Oracle或者PostgreSQL中期望的那样,SQLite没有通过计算各种替代查询计划并选择最快的候选计划来尝试判断优化路径。因此,假如您在大型数据集合上运行复杂的查询,SQLite与那些有复杂设计的查询计划器的数据库运行一样快的机会是非常小的。

一些情况下,SQLite可能不如大型数据库快,但大多数的这些情况是预期的。SQLite是为中小规模的应用程序设计的一个嵌入式的数据库,这些限制是设计目的预见到的。许多新用户错误地认为使用SQLite可以代替大型关系数据库。事实是有时可以这样做,有时不行,这完全取决于您准备用SQLite来做什么。

一般情况下,SQLite的局限性主要有以下两方面:

并发。SQLite的锁机制是粗粒度的,它允许多个读,但是一次只允许一个写。写锁会在写期间排他地锁定数据库,其他人在此期间不能访问数据库。SQLite已经采取措施以最小化排它锁所占用的时间。通常来讲,SQLite中的锁只保持几毫秒。但是按照一般经验,如果您的应用程序有很高的写并发(许多连接竞争向同一数据库写),并且是时间关键型,您可能需要其他数据库。需要实际测试您的应用程序才能知道能获得怎样的性能。作者曾见过一个简单的网络应用程序中,SQLite用100个并发连接每秒处理500多个事务。您的事务所修改的记录数以及查询所涉及的复杂性可能有所不同。什么样的并发性是可接受的,这取决于具体的应用程序,只能通过直接测试来判断。总之,对任何数据库都是真理:直到您做了实际测试才能知道应用程序能获得怎样的性能。

网络。虽然SQLite数据库可以通过网络文件系统共享,但是与这种文件系统相关的潜在延时会导致性能受损。更糟的是,网络文件系统实现中的一些缺陷也使得打开和修改远程文件--SQLite或其他--很容易出错。如果文件系统的锁实现不当,可能允许两个客户端同时修改同一个数据库文件,这样必然会导致数据库出错。实际上,并不是因为SQLite的实现导致SQLite不能在网络文件系统上工作。相反,SQLite在底层文件系统和有线协议下工作,但是这些技术有时并不完善。例如,许多NFS使用有缺陷的fcntl(),这意味着锁可能并不像设想的那样工作。一些较新版本的NFS,如Solaris NFSV4就可以工作正常,SQLite需要的锁机制也是相当可靠的。然而,SQLite开发者既没有时间,也没有资源去验证任何给定的网络文件系统在所有的情况下都可以无缺陷工作。

再次申明,绝大部分限制是有意设计的--它们是SQLite设计的结果。例如,支持高度的写并发会带来很大的复杂性,这将使SQLite的简单性无法保持。同样,作为嵌入式数据库,SQLite是有意不支持网络的。这一点并不奇怪。总之,SQLite不能做的都是它所能做的直接结果。它开始的设计就是一款模块化、简单、紧凑的以及易于使用的嵌入式关系数据库,它的基础代码都在使用它的程序员的掌握范围内。从多方面看,它能完成许多其他数据库不能做的事情,例如,运行在电力消耗实际上是一项制约因素的嵌入式环境中。

尽管SQLite的实现已经相当好了,但仍有部分特性未能实现,这些特性有:

完整的触发器支持。SQLite支持几乎所有的标准触发器功能,包括递归触发器和INSTEAD OF触发器。但是对于所有的触发器类型,当受触发器查询影响的每一行做评估时,SQLite需要FOR EACH ROW行为。ANSI SQL92也说明了当前不支持FOR EACH STATEMENT。

完整的修改表结构支持。目前只支持RENAME TABLE和ADD COLUMN类型的ALTER TABLE命令。其他类型的ALTER TABLE操作,例如DROP COLUMN、ALTER COLUMN以及ADD CONSTRAINT还未实现。

右外连接与全外连接。左外连接(LEFT OUT JOIN)已经支持,但是右外连接(RIGHT OUTER JOIN)和全外连接(FULL OUTER JOIN)还未实现。所有的右外连接在语义上都有相同的左外连接,相反也成立。通过简单逆向表的顺序和修改连接限制,左外连接可以作为右外连接的实现。全外连接可以通过组合左外连接和UNION以及在WHERE子句中进行恰当的NULL过滤实现。

可更新的视图。SQLite的视图使只读的,您不能在视图上执行DELETE、INSERT或者UPDATE语句。但是您可以创建一个启动对视图进行DELETE、INSERT或者UPDATE的触发器,在触发器内完成您需要执行的操作。

窗口功能。ANSI SQL99的新功能之一就是窗口功能。该功能提供结果集的后处理分析,例如排序、平均移动以及超前和滞后计算等。SQLite目前支持ANSI SQL92的一部分,因此,它不支持像RANK()、ROW_NUMBER()等。

授权和撤销。由于SQLite能读写普通的磁盘文件,因此,唯一可以应用的访问权限就是所在操作系统的普通文件的访问权限。授权(GRANT)和撤销(REVOKE)命令一般是在高端系统中使用的,这些系统中有多个用户,不同用户对数据库中的数据有不同的访问级别。SQLite模型中,应用程序是主用户,能够访问整个数据库。这种模型中的访问明确定义为应用程序级--具体地说,就是应用程序可以访问数据库文件。

除了这里列出的,SQLite Wiki上有个专门的页面列出SQLite不支持的SQL。网址是www.sqlite.org/cvstrac/wiki?p=UnsupportedSql

发布了270 篇原创文章 · 获赞 274 · 访问量 377万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览