Thanks. Regarding scaling 1.0 and 1.1 releases have a limit of 4 billion > records / store file so if you need to store 4 billion strings you > have to make sure every string fits in a single block. This limit will > be increased to 32 billion or more in the 1.2 release. >
Any timeline guidance on release 1.2? We would like to learn about any implementation supporting following claim on the main neo4j page. Does anyone know about sharding schemes and how would traverser work with distributed graph? - massive scalability. Neo4j can handle graphs of several *billion*nodes/relationships/properties on a single machine and can be sharded to scale out across multiple machines. > > -Johan > > On Mon, Jun 7, 2010 at 4:27 PM, Biren Gandhi <[email protected]> > wrote: > > Similar issue on my side as well. Test data is ok, but production data > > (100 million+ objects, 200 relationships per object and 10 properties > > per object, with multi-million queries per day about search and > > traversal) would need clear disk sizing calculations due to iops and > > other hardware limits in a monolithic storage model. > > > > Has anyone been able to use neo4j succeessfully in scaling needs > > similar to mentioned avove? > > > > -b > > > > On Jun 7, 2010, at 4:45 AM, Craig Taverner <[email protected]> wrote: > > > >>> Is there a specific constrain on disk space? Normally disk space > >>> isn't > >>> a problem... it's cheap and there's usually loads of it. > >>> > >> > >> Actually for most of my use cases the disk space has been fine. > >> Except for > >> one data source, that surprised me by expanding from less than a gig > >> of > >> original binary data, to over 20GB database. While this too can be > >> managed, > >> it was just a sample, and so I have yet to see what the customers > >> 'real > >> data' will do to the database (several hundred times larger, I'm > >> expecting). > >> When we get to that point we will need to decide how to deal with it. > >> Currently we 'solve' the issue by allowing the user to filter out > >> data on > >> import, so we don't store everything. This will not satisfy all users, > >> however. > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
