[Neo] Dispell the myth? FlockDB vs. Neo4j
neil.ellis at mangala.co.uk
Tue Apr 13 15:04:48 CEST 2010
I think fair comments Peter. It would make sense to look at what distinguishes Neo4J and of course (I'm sure you're doing this already) getting some serious benchmarks running on Sun's test environment (or wherever) so that there are easily comparable performance figures for the different uses of the two.
I'm sure Twitter have done a fine job of optimising a MySQL cluster to the needs of their way of using a social graph and in itself is an endeavour which may well be worthy of kudos on further inspection. And I don't want to detract from their own hard work (not sure why they didn't use a proven high speed graph DB myself - but then I am biased!).
Now is for sure the time to look at how they compare with each other.
Personally speaking, the way I use Neo4J I find it extremely hard to see how it would be made faster by sitting on top of a MySQL cluster - but I'm certainly still open to learning!
As you (kind of) mentioned partitioning really is the key to the whole thing here ... wouldn't it be nice if Neo4J gradually auto-partitioned a graph by the number of connections between nodes (i.e. clusters of nodes end up on the same partition) or maybe you can do that already? I know people fear lack of scaling on a graph database, though in reality I doubt too many people who fear that will ever actually max out Neo4J to the point it actually matters!
Anyway, the usual kudos to you guys, I've been busy re-writing the backend of cazcade.com in readiness for our new iPad application (shiny, shiny, shiny) and every step of the way Neo has just been a joy. It makes me think in the right way, unlike object DBs which make you think of a fully materialised object graph (never works for me) and relational databases which force an unnatural tabular view of the world (which is why I think of them as Domain Specific Databases these days!). I'm honestly so surprised how natural it has become to see almost everything as a graph and to really benefit from that view.
(Note: I am writing a form of social networking application so naturally we do see graphs everywhere!!!)
(Disclaimer: I don't benefit in any way from telling people how cool Neo4J is, it just is cool)
Are you guys going to be at the Monday 19th Meetup in London I presume?
On 13 Apr 2010, at 12:20, Peter Neubauer wrote:
> FlockDB seems to be focused on making the graph very flat (just
> user->followers) in order to be able to partition it. In that respect,
> it almost implements a document model. I think the most interesting to
> start with would be to implement it under Gremlin and run some algos
> on in in order to test. Emil will write up more on FlockDB, but I
> imagine the characteristics are more these of a Document DB than of a
> Graph DB.
> We will need to get a better grip on it before jumping to conclusions though.
> /peter neubauer
> COO and Sales, Neo Technology
> GTalk: neubauer.peter
> Skype peter.neubauer
> Phone +46 704 106975
> LinkedIn http://www.linkedin.com/in/neubauer
> Twitter http://twitter.com/peterneubauer
> http://www.neo4j.org - Your high performance graph database.
> http://nosqleu.org - The biggest NOSQL event. Ever.
> http://www.thoughtmade.com - Scandinavias coolest Bring-a-Thing party.
> On Tue, Apr 13, 2010 at 1:11 PM, Jeremy Day <jeremy.day at gmail.com> wrote:
>> I haven't looked at FlockDB at all, but would it be possible to perhaps
>> implement the Neo API on top of it?
>> On Tue, Apr 13, 2010 at 5:26 AM, Laurent Laborde <kerdezixe at gmail.com>wrote:
>>> I just heavily twitted about it :)
>>> I'd call FlockDB a Key/Value/Relationship Store (KVRstore), but not a
>>> graphdb :)
>>> Laurent "ker2x" Laborde
>>> Sysadmin & DBA at http://www.over-blog.com/
>>> Neo mailing list
>>> User at lists.neo4j.org
>> Neo mailing list
>> User at lists.neo4j.org
> Neo mailing list
> User at lists.neo4j.org
All the best
Tel/Fax: +44 (0) 20 7183 1318 | Skype: neilellis | AIM: neilellis at mac.com | Blog: http://web.mac.com/neilellis/
UK Company Reg No: 4557538 -- Vat Reg No: 815793111
More information about the User