有没有人使用基于图形的数据库（http://neo4j.org/）？ [英] Has anyone used Graph-based Databases (http://neo4j.org/)?
问题描述
我已经使用了关系数据库，并决定尝试其他类型的数据库。
这个特定的产品看起来不错，有希望： http://neo4j.org/
有没有人使用基于图形的数据库？
您是否在生产环境中使用了这些功能？
我在前一个作业中使用了图形数据库。我们没有使用neo4j，它是一个内部事件建立在Berkeley DB的顶部，但它是类似的。它用于生产（仍然是）。
我们使用图形数据库的原因是系统存储的数据和系统正在执行的操作数据正是关系数据库的弱点，正是图形数据库的强点。系统需要存储缺少固定模式并通过关系链接在一起的对象集合。要想了解数据，系统需要做很多操作，这将是一个图形数据库中的几次遍历，但这将是在SQL中非常复杂的查询。
<图形模型的主要优点是快速的开发时间和灵活性。我们可以快速添加新功能，而不会影响现有部署。如果潜在客户想要导入一些他们自己的数据并移植到我们的模型上，通常可以由销售代表在现场完成。当我们设计一个新功能时，灵活性也有所帮助，使我们无法将新数据挤入刚性数据模型。
有一个奇怪的数据库让我们构建了很多我们的其他奇怪的技术，给我们很多秘密酱，以区分我们的产品与我们的竞争对手的。
主要的缺点是我们没有使用标准的关系数据库技术，这可能是一个问题，当你的客户是企业家。我们的客户会问为什么我们不能仅仅将数据托管在其巨大的Oracle集群上（我们的客户通常有大型数据中心）。其中一个团队实际上重写了数据库层以使用Oracle（或PostgreSQL或MySQL），但它比原来慢一点。至少一个大型企业甚至有一个仅限Oracle的策略，但幸运的是Oracle购买了Berkeley DB。我们还必须写很多额外的工具 - 我们不能只使用水晶报表为例。
我们的图数据库的另一个缺点是，我们自己，这意味着当我们遇到一个问题（通常具有可扩展性），我们不得不自己解决它。如果我们使用关系数据库，供应商已经在十年前解决了这个问题。
如果你正在为企业客户构建一个产品，进入关系模型，如果可以的话，使用关系数据库。如果您的应用程序不适合关系模型，但它适合图形模型，请使用图形数据库。
如果您的应用程序不需要适应当前的blub架构，请使用图形数据库或CouchDB或BigTable ，或任何适合你的应用程序，你认为是很酷。
无论你选择什么，尽量不要自己建立数据库引擎，除非你真的喜欢建立数据库引擎。
I have used Relational DB's a lot and decided to venture out on other types available.
This particular product looks good and promising: http://neo4j.org/
Has anyone used graph-based databases? What are the pros and cons from a usability prespective?
Have you used these in a production environment? What was the requirement that prompted you to use them?
I used a graph database in a previous job. We weren't using neo4j, it was an in-house thing built on top of Berkeley DB, but it was similar. It was used in production (it still is).
The reason we used a graph database was that the data being stored by the system and the operations the system was doing with the data were exactly the weak spot of relational databases and were exactly the strong spot of graph databases. The system needed to store collections of objects that lack a fixed schema and are linked together by relationships. To reason about the data, the system needed to do a lot of operations that would be a couple of traversals in a graph database, but that would be quite complex queries in SQL.
The main advantages of the graph model were rapid development time and flexibility. We could quickly add new functionality without impacting existing deployments. If a potential customer wanted to import some of their own data and graft it on top of our model, it could usually be done on site by the sales rep. Flexibility also helped when we were designing a new feature, saving us from trying to squeeze new data into a rigid data model.
Having a weird database let us build a lot of our other weird technologies, giving us lots of secret-sauce to distinguish our product from those of our competitors.
The main disadvantage was that we weren't using the standard relational database technology, which can be a problem when your customers are enterprisey. Our customers would ask why we couldn't just host our data on their giant Oracle clusters (our customers usually had large datacenters). One of the team actually rewrote the database layer to use Oracle (or PostgreSQL, or MySQL), but it was slightly slower than the original. At least one large enterprise even had an Oracle-only policy, but luckily Oracle bought Berkeley DB. We also had to write a lot of extra tools - we couldn't just use Crystal Reports for example.
The other disadvantage of our graph database was that we built it ourselves, which meant when we hit a problem (usually with scalability) we had to solve it ourselves. If we'd used a relational database, the vendor would have already solved the problem ten years ago.
If you're building a product for enterprisey customers and your data fits into the relational model, use a relational database if you can. If your application doesn't fit the relational model but it does fit the graph model, use a graph database. If it only fits something else, use that.
If your application doesn't need to fit into the current blub architecture, use a graph database, or CouchDB, or BigTable, or whatever fits your app and you think is cool. It might give you an advantage, and its fun to try new things.
Whatever you chose, try not to build the database engine yourself unless you really like building database engines.
这篇关于有没有人使用基于图形的数据库（http://neo4j.org/）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
