在过去一年左右的时间里，我一直在使用 Django 进行开发，而且真的
好好享受。但有时我发现 ORM 有点
紧身衣。我来回移动的所有数据
数据库可以轻松装入 1GB RAM。即使项目增长了
几个数量级，它仍然适合 1GB。
我想要一个解决方案，我的应用程序只需要从磁盘读取
在启动时但在更新对象时隐式写入磁盘。我
不太关心这可能给我带来的任何速度提升。什么
我真正追求的是增加的灵活性。如果我有一个问题
非常适合链表、树或其他一些东西
数据结构，我不应该将其移植到关系上
数据库。
Python 会很好，但其他语言也可以。我正处于探索之中
这一阶段。我想了解一下解决方案是什么
在那里。当谷歌搜索这个问题时，我得到了很多与以下内容相关的点击：
不同的Nosql项目。但据我了解，Nosql 的意义在于
当你的关系数据库不够用时你会做什么，因为你已经拥有太多
很多数据。我确实处于光谱的另一端。我有这样的
很少的数据表明关系数据库实际上是大材小用。
对象数据库是一个
谷歌搜索这个问题时出现的另一件事，提醒了
我是 Zope 和 ZODB。我很久以前就接触过 Zope，真的
不喜欢它。但是阅读了一些关于对象数据库的内容让我认为
可能是我正在寻找的。话又说回来，他们普遍未能
吸引用户让我产生怀疑。对象数据库已经存在
很长一段时间了，但仍然没有流行起来。我猜
这意味着他们有问题吗？
I've been developing with Django during the last year or so and really
enjoy it. But sometimes I find that the ORM is a bit of a
straitjacket. All the data that I shuffle back and forth to the
database would easily fit into 1GB of RAM. Even if the project grew a
couple of orders of magnitude it would still fit into 1GB.
I'd like a solution where my application only needs to read from disk
at startup but writes to disk implicitly as I update my objects. I
don't care to much about any speed increase this might give me. What
I'm really after is the added flexibility. If I have a problem that
would fit nicely with a linked list or a tree or some other
data structure, I shouldn't have to graft that onto a relational
database.
Python would be nice but other languages are fine. I'm in the exploratory
phase on this one. I want to get a feel for what solutions are
out there. When googling this question I got a lot of hits related to
different Nosql projects. But Nosql, as I understand it, is all about
what you do when you outgrow relational databases because you've got too
much data. I'm really at the other end of the spectrum. I've got so
little data that a relational database is actually overkill.
Object databases is an
other thing that came up when googling this question, which reminded
me of Zope and ZODB. I dabbled a bit with Zope an eon ago and really
disliked it. But reading up a bit on object databases made me think that it
might what I'm looking for. Then again, their general failure to
attract users makes me suspicious. Object databases have been around
for a very long time and still haven't caught on. I guess
that means there's something wrong with them?
发布评论
评论（2）
如果您正在寻找“在内存中存储数据结构”和“将它们备份到磁盘”，那么您实际上正在寻找持久缓存系统和Redis 完全符合要求。
如果你想使用 django，有一个很棒的内置缓存系统，可以通过 Redis-Cache 项目。此外，redis 所容纳的数据结构与 python 数据结构具有一对一的映射，因此非常无缝。
我不太确定跳过数据库本身的概念是否是一个好主意。数据库在聚合、注释、关系等方面提供了如此强大的功能，所有这些都在可接受的性能水平内，直到达到真正的大规模。
也许另一个想法是使用 SQLite 内存数据库。 SQLite 如今已经无处不在，它已经消失在基础设施中。它是内置的 Android 应用程序、iPhone 应用程序，并且拥有所有标准库的支持。它也是一个非常棒的软件，开发和测试得非常好，很难提出任何反对使用它的理由。
If you are looking for "storing data-structures in-memory" and "backing up them to disk", you are really looking for a persistent cache system and Redis fits the bill perfectly.
If you want to use django, there is an awesome cache system built-in and that is pluggable to redis backend via Redis-Cache project. More over the data-structures accomodated by redis have one-to-one mapping to python data-structures, and so it is pretty seamless.
I am not so sure if skipping the concept of database itself, is a good idea. Database provides so much power in terms of aggregating, annotating, relations etc, all within acceptable performance levels until you hit real large scale.
Perhaps another idea would be to to use SQLite in-memory database. SQLite is so ubiquitous these days, it has disappeared into the infrastructure. It is built in, Android apps, iphone ones and has support from all standard libraries. It is also an awesome software developed and tested so well, it is very hard to make any case against using it.
我工作的公司（Starcounter）创建了一个完全按照您描述的方式工作的数据库。我们已经与合作伙伴客户一起运行该数据库几年了，即将公开该产品。我们创建它的主要原因是为了易于使用和性能。如果您在我们的企业论坛上向我发送消息（我是 Starconter Jack），我将很乐意向您发送一份副本。
关于面向对象数据库的主题； OO数据库失败的原因主要是因为它们只是实验而不是真正的产品。它们的实现很差，仅支持 OO 范式，而忽略了 SQL 和 ODBC 等标准。他们还缺乏稳定性、表现和成熟度。他们的故事类似于 iPhone、iPad 和 Kindle 出现前一两年的早期平板电脑、电子书和智能手机。
但就像任何技术一样，有两个浪潮（查找“炒作周期”）。虽然第一波会令人失望，但第二波会很好。第一个将由概念和想法驱动，缺乏商业上的成功和现实生活中的可用性。第二波浪潮将不想与第一波失败的霉味有任何关系，因此将使用新的缩写词和流行语。
未来的数据库将源于 NoSQL 运动。它将添加 SQL 支持，许多人会认为这是新颖的。它将增加良好的语言集成（大多数语言都是 oo），许多人会认为这也是新颖的。它将支持文档，许多人会认为这很新颖。许多人会重新发现交易等的需要。
一些脾气暴躁的老人会试图告诉我们，我们所做的只是重新发明现有的想法。从某种程度上来说，他们是对的。在某些方面他们不会。这一次，概念已经成熟。将添加新的想法并允许实用主义。
但话又说回来，iPad 在某种程度上仍然是 PDA。
The company I work for (Starcounter) creates a database that works exactly in the way that you describe. We have been running the database for a few years with our partner customers and are about to make the product publicly available. The main reason we created it is for ease of use and performance. I'll be happy to send you a copy if you send me a message on our corporate forum (I’m Starconter Jack).
On the subject on OO databases; the reason that OO databases failed is mainly because they were more experiments than real products. They were poorly implemented, supported only the OO paradigm and ignored standards such as SQL and ODBC. They also lacked stability, performance and maturity. Their story is analogues to the early tablets, eBooks and smartphones a decade or two before the iPhone, iPad and Kindle.
But just as with any technology, there are two waves (look up "the hype cycle"). While the first wave will disappoint, the second wave will be good. The first one will be driven by the concepts and ideas and will lack commercial success and real life usability. The second wave will want nothing to do with the musty smell of the failures of the first one and will therefore use new and fresh acronyms and buzzword.
The future database will spring out of the NoSQL movement. It will have added SQL support and many will think this is novel. It will have added good language integration (and most languages are oo) and many will think this is also novel. It will support documents and many will think this will be novel. Many will rediscover the need for transactions etc. etc.
Some grumpy old men will try to tell us that all we have done is to reinvent existing ideas. In some way they will be right; in some ways they won’t. This time around, the concepts are matured. New ideas will be added and pragmatism will be allowed.
But then again, an iPad is still, in a way, a PDA.