Hi,
These are the current record sizes in bytes that can be used to
calculate the actual store size:
nodestore: 9
relationshipstore: 33
propertystore: 25
stringstore: 133
arraystore: 133
All properties except strings and arrays will take a single
propertystore record (25 bytes). A string or
Hi,
Maybe we should add a configuration option so that ids are not reused.
Martin, you could try patch the code in
org.neo4j.kernel.impl.nioneo.store.IdGeneratorImpl:
===
--- IdGeneratorImpl.java(revision 4480)
+++
Peter,
I can obviously send you by email my current work in progress but, as I
told you, I have some difficulties linked to the way Neo4j is designed.
As I told you in my previous mail, it would be much better for Cassandra
to use non-long ids.
Another main point is that Cassandra does not need
Hi,
I'm using it!
I agree that the transactions shouldn't be there.
But it could be excused by the fact that neo4j ignores nested
transactions (I think?)
So it doesn't really break any existing transactions and yields the
expected behavior when not in a transaction.
Furthermore, if you remove
I tend to write xxxTX() and xxxNoTX methods so the user can see
instantly if the methods contain a TX.
All the best
Neil Ellis
(Sent from my iPhone)
On 7 Jun 2010, at 11:14, Wouter De Borger w.debor...@gmail.com wrote:
Hi,
I'm using it!
I agree that the transactions shouldn't be there.
Seems that the string store is not optimal for the 'common' usage of
properties for names or labels, which are typically 5 to 20 characters long,
leading to about 5x (or more) space utilization than needed. By 'names or
labels' I mean things like username, tags, categorizations, product names,
Jawad,
if you sign the CLA,
http://wiki.neo4j.org/content/About_Contributor_License_Agreement, we
might open a new branch in the laboratory to keep that code and sync
it with the kernel?
Cheers,
/peter neubauer
COO and Sales, Neo Technology
GTalk: neubauer.peter
Skype peter.neubauer
2010/6/7 Craig Taverner cr...@amanzi.com:
Seems that the string store is not optimal for the 'common' usage of
properties for names or labels, which are typically 5 to 20 characters long,
leading to about 5x (or more) space utilization than needed. By 'names or
labels' I mean things like
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
Disk space is cheap, yes, but of course there is a performance cost to
read from it. More importantly, do the same record sizes apply to the
in-memory representation of properties? If so, that might be an issue,
since memory is a more precious commodity. If not, then doing a
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
Hi Davide and others,
I'm trying to convert the current RTree implementation to use the
BatchInserter to improve performance during bulk loads. But of course there
is a serious catch. The BatchInserter disallows deletion actions and the
RTree needs to delete relationships when splitting the
Hi list,
in my application I need to iterate over all nodes and relationships to
add some versioning information to them. For performance reasons I am
using the batch inserter to add this. Unfortunately it doesn't seem to
provide a way to retrieve all node and relationship IDs so I have to
hi users,im a newbie,,trying to install Neo4j rest server..
I downlded the zip file n placed it in the bin of the java..
then on the cmd ,i wrote
D:\cd java
D:\javacd jre6
D:\java\jre6cd bin
D:\java\jre6\bincd neo4j
D:\java\jre6\bin\neo4jcd bin
D:\java\jre6\bin\neo4j\binneo4j-rest install
The BatchInserter is to be considered a write-only interface. Reads in
BatchInserter may be (really) slow, since the purpose of it is to be
optimized for (sequential) writes. As a rule of thumb, when you are doing
anything other than importing a large initial dataset, you should use the
regulare
15 matches
Mail list logo
