max*_*max 4 python sqlite performance
我注意到我的(纯Python)代码的很大一部分处理表.当然,我class Table支持基本功能,但我最终添加了越来越多的功能,如查询,验证,排序,索引等.
我想知道删除我是否是一个好主意class Table,并重构代码以使用我将在内存中实例化的常规关系数据库.
这是我到目前为止的想法:
查询和索引的性能会提高,但Python代码和单独的数据库进程之间的通信可能比Python函数之间的效率低.我认为这是太多的开销,所以我不得不使用Python附带的sqlite并且生活在同一个进程中.我希望这意味着它是纯粹的性能提升(以非标准SQL定义和sqlite的有限功能为代价).
使用SQL,我将获得比我自己想要的更强大的功能.看起来像一个明显的优势(即使使用sqlite).
我不需要调试我自己的表实现,但是SQL中的调试错误很难,因为我不能放置断点或者很容易打印出临时状态.我不知道如何判断代码可靠性和调试时间的整体影响.
代码将更容易阅读,因为我不会调用自己的自定义方法而是编写SQL(每个需要维护此代码的人都知道SQL).但是,处理数据库的Python代码可能比使用纯Python的代码更加丑陋和复杂class Table.同样,我不知道哪个更好平衡.
对上述内容的任何更正,或者我应该考虑的任何其他内容？
SQLite不在单独的进程中运行.所以你实际上没有IPC的任何额外开销.但是,无论如何,IPC开销并不是那么大,特别是在UNIX套接字上.如果你需要多个编写器(多个进程/线程同时写入数据库),锁定开销可能更糟,MySQL或PostgreSQL的性能会更好,特别是如果在同一台机器上运行.所有这三个数据库支持的基本SQL都是相同的,因此基准测试并不那么痛苦.
您通常不必像在自己的实现上那样对SQL语句执行相同类型的调试.SQLite可以工作,并且已经很好地调试了.您不太可能必须调试"好的,该行存在,为什么数据库找不到它？" 并追踪索引更新中的错误.调试SQL与过程代码完全不同,实际上只有非常复杂的查询才会发生.
至于调试代码,你可以相当容易地集中你的SQL调用并添加跟踪来记录你正在运行的查询,你得到的结果等等.Python SQLite接口可能已经有了这个(不确定,我通常使用Perl) .将现有的Table类作为SQLite的包装器可能是最容易的.
我强烈建议不要重新发明轮子.SQLite将会有更少的错误,并为您节省大量时间.(你可能也想看看Firefox最近转向使用SQLite来存储历史记录等等,我认为这样做会有一些非常显着的加速.)
此外,SQLite优化良好的C实现可能比任何纯Python实现快得多.