Re: [orientdb] Trouble using In-memory DB and distributed mode ..

[Mahesh Wabale]

Hi Luca , 

 Thank you for reply , Now i am moving from memory to plocal storage for 
distributed graph database .  Orientdb helped me alot through this analysis 
process . Got to learn many things. Orientdb created new era in graph 
databases . I hope it is future of technology .  

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: Complex query

[Ziink A]

Sorry, I don't have an answer but I'd explore one of the following options.

1. UNIONALL
2. both() for Vertex, bothE() for count, group by

On Monday, June 1, 2015 at 3:10:15 PM UTC-7, Andrey Yesyev wrote:
>
> Hi there,
>
> I need help with a query.
> My schema is pretty simple. Vertices are connected with Edges of type 
> RELATED which have property count.
> 2 vertices can have connection in both ways at the same time.
>
> V1--RELATED(count=17)-->V2
>
> V2--RELATED(count=3)-->V1
>
> I need to build a query that for vertex Vn, will find all vertices 
> connected with RELATED edge to this Vn and also, for each pair [Vn, Vx] 
> will calculate SUM of in_RELATED.count and out_RELATED.count.
>
> For that simple example above, this query result for V1 would be
>
> |  Vertex   |Count|
> ||
> |V2  |  20|
>
> Is it possible to do in one query at all?
>
> Any help is very much appreciated!
>
> -Andrey
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: possible to create a class extends from multiple classes?

[Ziink A]

Yes you can have multiple inheritance in the newer versions. 

create class C extends A, B;

alter class C superclasses A, B;

--Add A superclass
alter class C superclass +A;  

--Remove B superclass 
alter class C superclass -B;   

Follow the link for more details.
https://github.com/orientechnologies/orientdb/pull/3802


On Monday, June 1, 2015 at 2:45:17 PM UTC-7, Zhuo Bao wrote:
>
> when creating complicated objects (class), a logically plausible method is 
> to create them from multiple classes:
> an event class is composed by:
> 1, datetime class
> 2, geolocation class
> 3, weather class
> 4, people class
> 
>
> could this be possible in orientdb?
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Trouble using In-memory DB and distributed mode ..

[Luca Garulli]

That post is pretty old. You can work with distributed databases only by
using "plocal". Unfortunately the support also for "memory" is 90% done,
but not completed.

Best Regards,

Luca Garulli
CEO at Orient Technologies LTD
the Company behind OrientDB
http://about.me/luca.garulli


On 2 June 2015 at 08:36, Mahesh Wabale  wrote:

>
>>
>>
>
>
> On Monday, October 13, 2014 at 7:58:02 PM UTC+5:30, Lvc@ wrote:
>>
>> Hi,
>> In-Memory database + Distributed works only in 2.0. Please could you try
>> with 2.0-SNAPSHOT?
>>
>> Lvc@
>>
>> ᐧ
>>
>>
> Hi luca ,
>
> Are you talking about plocal database with cache . Is it correct ?
>
> I am confuse in  in-memory database , i think this is whole about memory
> storage ?  Can you elaborate please
>
> Thanks in advance .
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: Edge Query Issue

[Thomas Kennedy]

Correction it gives me the below record but I want to expand the 
out('registered_events') relationship

METADATAPROPERTIESOUT
@rid
@version
@class
hour
registered_events
#24:7 
41
Hour23
#27:0 
 
#27:1 
 
#27:2 
 
#27:3 
 
#27:4 
 
#27:5 
 

On Tuesday, 2 June 2015 23:39:55 UTC+1, Thomas Kennedy wrote:
>
> I have a time series model where I create an edge between a hour vertex 
> and an event vertex. The edge is called registered_event.
>
> I have tried the following query but it is not giving me results. Any 
> ideas?
>
> select expand(month[12].day[3].hour[23]).out('registered_event') from Year 
> where year = 2015
>
>
On Tuesday, 2 June 2015 23:39:55 UTC+1, Thomas Kennedy wrote:
>
> I have a time series model where I create an edge between a hour vertex 
> and an event vertex. The edge is called registered_event.
>
> I have tried the following query but it is not giving me results. Any 
> ideas?
>
> select expand(month[12].day[3].hour[23]).out('registered_event') from Year 
> where year = 2015
>
>
On Tuesday, 2 June 2015 23:39:55 UTC+1, Thomas Kennedy wrote:
>
> I have a time series model where I create an edge between a hour vertex 
> and an event vertex. The edge is called registered_event.
>
> I have tried the following query but it is not giving me results. Any 
> ideas?
>
> select expand(month[12].day[3].hour[23]).out('registered_event') from Year 
> where year = 2015
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Edge Query Issue

[Thomas Kennedy]

I have a time series model where I create an edge between a hour vertex and 
an event vertex. The edge is called registered_event.

I have tried the following query but it is not giving me results. Any ideas?

select expand(month[12].day[3].hour[23]).out('registered_event') from Year 
where year = 2015

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Time Series Last Node Link

[Thomas Kennedy]

I have a time series modelled in the graph way

year(linkmap)->month(linkmap)->day(linkmap)->hour(linkmap)

I have two other vertices which are events and users

I want to join events to the time series. Is this best achieved by using an 
edge or a linkset? 

year(linkmap)->month(linkmap)->day(linkmap)->hour(linkmap)-> ?Edge|Linkset? 
Event -> User

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: Sources for orientdb community 2.0.10

[Andrey Yesyev]

Never mind, found 
them https://github.com/orientechnologies/orientdb/releases

On Tuesday, June 2, 2015 at 4:19:36 PM UTC-4, Andrey Yesyev wrote:
>
> How to get sources for the latest stable release 2.0.10.
>
> I looked at git, there is no specific branch for 2.0.10, I ended up 
> getting 2.0.x, which doesn't fit to binaries from 2.0.10.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Sources for orientdb community 2.0.10

[Andrey Yesyev]

How to get sources for the latest stable release 2.0.10.

I looked at git, there is no specific branch for 2.0.10, I ended up getting 
2.0.x, which doesn't fit to binaries from 2.0.10.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] How to have Orientdb shard in distributed mode?

[Darren Blaber]

Hello,
I have seen older references to sharding 
(https://groups.google.com/forum/#!searchin/orient-database/shard/orient-database/DqXQ9qPYo5w/EPP0y-y0H20J).
 
Is it still possible to have orientdb (2.1) to automatically shard? In the 
documentation I am reading, it says cluster strategy is to always prefer 
local, which I am guessing whatever server the client is connecting to will 
get the data. Do any of the other cluster selection strategies work, such 
as round robin, balanced or even writing out own java cluster selection 
strategy work? 

Also, is it possible configure sharding generically for all tables? I tried 
changing distributed-db-config.json and using the *, and listing the nodes 
I want it replicated to, but how do you specify sharding?

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: Exception "Cluster with id 5 already belongs to class OUser"

[Andrey Yesyev]

Version orientdb-community 2.0.10.
Connection remote.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Exception "Cluster with id 5 already belongs to class OUser"

[Andrey Yesyev]

I'm creating DB this way

if (url.startsWith("remote")) {
OServerAdmin server = new OServerAdmin(url).connect(userName, password);
if (!server.existsDatabase("plocal")){
server.createDatabase("graph", "plocal");
}
server.close();

factory = new OrientGraphFactory(endpoint.get(), userName, password);
factory.setupPool(5, 100);
}


from created factory I'm trying to acquire connection 

OrientGraph g = factory.getTx();


That's where I'm getting OSchemaException *Cluster with id 5 already 
belongs to class OUser.*

Stack trace

com.orientechnologies.orient.core.exception.OSchemaException: Cluster with 
id 5 already belongs to class OUser
at 
com.orientechnologies.orient.core.metadata.schema.OSchemaShared.checkClustersAreAbsent(OSchemaShared.java:808)
at 
com.orientechnologies.orient.core.metadata.schema.OSchemaShared.createClass(OSchemaShared.java:216)
at 
com.orientechnologies.orient.core.metadata.schema.OSchemaShared.createClass(OSchemaShared.java:153)
at 
com.orientechnologies.orient.core.metadata.schema.OSchemaShared.createClass(OSchemaShared.java:145)
at 
com.orientechnologies.orient.core.metadata.schema.OSchemaShared.createClass(OSchemaShared.java:133)
at 
com.orientechnologies.orient.core.metadata.schema.OSchemaShared.getOrCreateClass(OSchemaShared.java:174)
at 
com.orientechnologies.orient.core.metadata.schema.OSchemaShared.getOrCreateClass(OSchemaShared.java:157)
at 
com.orientechnologies.orient.core.metadata.schema.OSchemaProxy.getOrCreateClass(OSchemaProxy.java:67)
at 
com.orientechnologies.orient.core.record.ORecordSchemaAwareAbstract.setClassName(ORecordSchemaAwareAbstract.java:130)
at 
com.orientechnologies.orient.core.record.impl.ODocument.(ODocument.java:193)
at 
com.orientechnologies.orient.core.type.ODocumentWrapper.(ODocumentWrapper.java:45)
at 
com.orientechnologies.orient.core.metadata.security.OUser.(OUser.java:64)
at 
com.orientechnologies.orient.core.db.record.ODatabaseRecordAbstract.open(ODatabaseRecordAbstract.java:310)
at 
com.orientechnologies.orient.core.db.ODatabaseWrapperAbstract.open(ODatabaseWrapperAbstract.java:54)
at 
com.orientechnologies.orient.core.db.document.ODatabaseDocumentTxPooled.(ODatabaseDocumentTxPooled.java:47)
at 
com.orientechnologies.orient.core.db.document.ODatabaseDocumentPool.createResource(ODatabaseDocumentPool.java:44)
at 
com.orientechnologies.orient.core.db.document.ODatabaseDocumentPool.createResource(ODatabaseDocumentPool.java:20)
at 
com.orientechnologies.orient.core.db.ODatabasePoolBase$1.createNewResource(ODatabasePoolBase.java:74)
at 
com.orientechnologies.orient.core.db.ODatabasePoolBase$1.createNewResource(ODatabasePoolBase.java:63)
at 
com.orientechnologies.common.concur.resource.OResourcePool.getResource(OResourcePool.java:84)
at 
com.orientechnologies.orient.core.db.ODatabasePoolAbstract.acquire(ODatabasePoolAbstract.java:93)
at 
com.orientechnologies.orient.core.db.ODatabasePoolAbstract.acquire(ODatabasePoolAbstract.java:78)
at 
com.orientechnologies.orient.core.db.ODatabasePoolBase.acquire(ODatabasePoolBase.java:105)
at 
com.tinkerpop.blueprints.impls.orient.OrientBaseGraph.(OrientBaseGraph.java:90)
at 
com.tinkerpop.blueprints.impls.orient.OrientTransactionalGraph.(OrientTransactionalGraph.java:39)
at 
com.tinkerpop.blueprints.impls.orient.OrientGraph.(OrientGraph.java:54)
at 
com.tinkerpop.blueprints.impls.orient.OrientGraphFactory.getTx(OrientGraphFactory.java:49)
at 
com.ibm.qradar.forensics.indexer.di.Database.getConnection(Database.java:79)
at 
com.ibm.qradar.forensics.indexer.di.Database.addType(Database.java:202)
at 
com.ibm.qradar.forensics.indexer.di.Database.initClasses(Database.java:168)
at 
com.ibm.qradar.forensics.indexer.di.Database.setupDB(Database.java:122)
at 
com.ibm.qradar.forensics.indexer.di.Database.(Database.java:69)
at 
com.ibm.qradar.forensics.indexer.di.DatabaseManager.getDatabase(DatabaseManager.java:35)
at 
com.ibm.qradar.forensics.indexer.di.DatabaseManager.getDatabase(DatabaseManager.java:43)
at 
com.ibm.qradar.forensics.indexer.di.ePersonaGraphIndexer.(ePersonaGraphIndexer.java:44)
at 
com.ibm.qradar.forensics.indexer.XMLFileReader.init(XMLFileReader.java:80)
at 
com.ibm.qradar.forensics.indexer.XMLFileReader.call(XMLFileReader.java:94)
at 
com.ibm.qradar.forensics.indexer.XMLFileReader.call(XMLFileReader.java:22)
at java.util.concurrent.FutureTask.run(FutureTask.java:274)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
at java.lang.Thread.run(Thread.java:801)



-- 

--- 
You received this message because you are subscribed

Re: [orientdb] How fast should OrientGraph.query() be?

[Nick DeYoung]

" Blueprints is nice, but it is not a cross-graph-database panacea."

there is much wisdom in this, that I think the graph community could use to
hear from.



On Tue, Jun 2, 2015 at 9:53 AM, W. Craig Trader 
wrote:

> Nick ...
>
> (1) I don't work for OrientDB, (2) I am not familiar with the Tinkerpop
> APIs outside of OrientDB.
>
> OrientGraph.getVertices() returns an iterator, not a pipe. Gremlin adds a
> DSL method *_()* that will turn an iterator into a pipeline, from which
> you can do the normal Gremlin queries.
>
> AFAIK, the OrientDB Java/Groovy/Gremlin APIs require you to explicitly
> select an index to use. The SQL queries can either explicitly specify an
> index (SELECT * from INDEX:...) or they may take advantage of an existing,
> properly specified, index, maybe. This is an area where OrientDB still
> needs a lot of work, IMO.  Or at least a lot more documentation.
>
> FWIW, I've been working with databases all my career, and I've never moved
> from one database to a different but comparable database without having to
> make changes to *some* aspect of my application. Blueprints is nice, but
> it is not a cross-graph-database panacea.
>
> - Craig -
>
> On Tue, Jun 2, 2015 at 12:35 PM, Nick DeYoung 
> wrote:
>
>> Craig,
>>
>> I have tried that, it takes 11 ms. but that is not a Pipe -
>> (g.getVertices())
>>
>> our code base is leveraging another TinkerPop enabled graph databse and
>> are researching the idea of switching it out.
>>
>> my research is trying to figure out how does orient perform on the
>> generic Tinkerpop API.
>> I want to do things like
>> g.V().has("someProperty","someValue").outE("someLabel")somemoreStepsInMyPipe..
>> and know that that is going to hit indexes.
>>
>> Does it ?
>>
>> this is a simple test of the different ways I am accessing the graph and
>> their timing on 300,000 vertices (not connected at the momen)
>>
>>  time("orient graph api 'orient specific'") {
>> val v = g.getVertices("V.testProperty",
>> "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e")
>>
>> } 11 ms
>>
>> time("tinkerpop pipeline 'generic'") {
>>   val v = new GremlinPipeline(g, true).V("testProperty",
>> "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e").next()
>>
>> } 21 seconds
>>
>> time ("another blueprints? " ) {
>>   val v = g.query().has("testProperty",
>> "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e").vertices()
>>
>> } 19 seconds
>>
>> time("sql count all 'orient specific'") {
>>   val v:OResultSet[ODocument] = g.getRawGraph.query(
>> new OSQLSynchQuery[ODocument]("select * from
>> INDEX:V.testProperty where key = 'cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e'")
>>   ) 1 ms
>>
>>
>> }
>>
>> // throws an error in distrubuted mode
>> //time ("gremlin command 'generic' ") {
>> //  val r = g.getRawGraph.command(new
>> OCommandGremlin("g.V().has('testProperty')")).execute()
>> //}
>>
>>
>> If I understand Orient's documentation right, I am going to have to
>> either change our pipes (traversals in tinkerpop) into SQL+ queries in
>> order to leverage the claims of orient's speed.
>>
>> If i'm wrong in this, let me know
>>
>>
>>
>>
>> On Mon, Jun 1, 2015 at 11:33 PM, W. Craig Trader 
>> wrote:
>>
>>> Nick ...
>>>
>>> Much like you told the SQL engine to use an index (select * from
>>> INDEX:V.testProperty ...), you need to explicitly use indexes from the
>>> graph API, as follows:
>>>
>>> *Java:*
>>>
>>> OrientVertex result = g.getVertices( "V.testProperty", "
>>> cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e" ).iterator().next();
>>>
>>>
>>> *Gremlin:*
>>> GremlinPipeline p = g.getVertices( "V.testProperty", "
>>> cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e" )._()
>>>
>>>
>>> I think you'll find that using indexes with the Java API is even faster
>>> than the SQL query API.
>>> - Craig -
>>>
>>>
>>> On Mon, Jun 1, 2015 at 5:33 PM, Nick DeYoung 
>>> wrote:
>>>
 I have an orient db 2.0.10 community server up and running
 I have created a simple test where I have placed 300,000 vertices in an
 orient database each with a property "testProperty" with a value -
 UUID.randomUUID().toString
 I have created an index on the property

   graph.createKeyIndex("testProperty", classOf[Vertex])  // this is
 scala :)

 In a  test I create an OrientGraph connected via remote:
 127.0.0.1:2424/test-database

 and do

 g.query().has("testProperty", "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e")

 This takes 20 seconds to return the vertex with that UUID.

 In another test I do

 g.getRawGraph.query(new OSQLSynchQuery[ODocument]("select * from
 INDEX:V.testProperty where key = 'cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e'"))

 which takes 1 millisecond to return the vertex.

 Is the java graph query api really this slow or am I doing something
 wrong?










  --

 ---
>>

Re: [orientdb] How fast should OrientGraph.query() be?

[W. Craig Trader]

Nick ...

(1) I don't work for OrientDB, (2) I am not familiar with the Tinkerpop
APIs outside of OrientDB.

OrientGraph.getVertices() returns an iterator, not a pipe. Gremlin adds a
DSL method *_()* that will turn an iterator into a pipeline, from which you
can do the normal Gremlin queries.

AFAIK, the OrientDB Java/Groovy/Gremlin APIs require you to explicitly
select an index to use. The SQL queries can either explicitly specify an
index (SELECT * from INDEX:...) or they may take advantage of an existing,
properly specified, index, maybe. This is an area where OrientDB still
needs a lot of work, IMO.  Or at least a lot more documentation.

FWIW, I've been working with databases all my career, and I've never moved
from one database to a different but comparable database without having to
make changes to *some* aspect of my application. Blueprints is nice, but it
is not a cross-graph-database panacea.

- Craig -

On Tue, Jun 2, 2015 at 12:35 PM, Nick DeYoung 
wrote:

> Craig,
>
> I have tried that, it takes 11 ms. but that is not a Pipe -
> (g.getVertices())
>
> our code base is leveraging another TinkerPop enabled graph databse and
> are researching the idea of switching it out.
>
> my research is trying to figure out how does orient perform on the generic
> Tinkerpop API.
> I want to do things like
> g.V().has("someProperty","someValue").outE("someLabel")somemoreStepsInMyPipe..
> and know that that is going to hit indexes.
>
> Does it ?
>
> this is a simple test of the different ways I am accessing the graph and
> their timing on 300,000 vertices (not connected at the momen)
>
>  time("orient graph api 'orient specific'") {
> val v = g.getVertices("V.testProperty",
> "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e")
>
> } 11 ms
>
> time("tinkerpop pipeline 'generic'") {
>   val v = new GremlinPipeline(g, true).V("testProperty",
> "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e").next()
>
> } 21 seconds
>
> time ("another blueprints? " ) {
>   val v = g.query().has("testProperty",
> "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e").vertices()
>
> } 19 seconds
>
> time("sql count all 'orient specific'") {
>   val v:OResultSet[ODocument] = g.getRawGraph.query(
> new OSQLSynchQuery[ODocument]("select * from
> INDEX:V.testProperty where key = 'cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e'")
>   ) 1 ms
>
>
> }
>
> // throws an error in distrubuted mode
> //time ("gremlin command 'generic' ") {
> //  val r = g.getRawGraph.command(new
> OCommandGremlin("g.V().has('testProperty')")).execute()
> //}
>
>
> If I understand Orient's documentation right, I am going to have to either
> change our pipes (traversals in tinkerpop) into SQL+ queries in order to
> leverage the claims of orient's speed.
>
> If i'm wrong in this, let me know
>
>
>
>
> On Mon, Jun 1, 2015 at 11:33 PM, W. Craig Trader 
> wrote:
>
>> Nick ...
>>
>> Much like you told the SQL engine to use an index (select * from
>> INDEX:V.testProperty ...), you need to explicitly use indexes from the
>> graph API, as follows:
>>
>> *Java:*
>>
>> OrientVertex result = g.getVertices( "V.testProperty", "
>> cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e" ).iterator().next();
>>
>>
>> *Gremlin:*
>> GremlinPipeline p = g.getVertices( "V.testProperty", "
>> cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e" )._()
>>
>>
>> I think you'll find that using indexes with the Java API is even faster
>> than the SQL query API.
>> - Craig -
>>
>>
>> On Mon, Jun 1, 2015 at 5:33 PM, Nick DeYoung 
>> wrote:
>>
>>> I have an orient db 2.0.10 community server up and running
>>> I have created a simple test where I have placed 300,000 vertices in an
>>> orient database each with a property "testProperty" with a value -
>>> UUID.randomUUID().toString
>>> I have created an index on the property
>>>
>>>   graph.createKeyIndex("testProperty", classOf[Vertex])  // this is
>>> scala :)
>>>
>>> In a  test I create an OrientGraph connected via remote:
>>> 127.0.0.1:2424/test-database
>>>
>>> and do
>>>
>>> g.query().has("testProperty", "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e")
>>>
>>> This takes 20 seconds to return the vertex with that UUID.
>>>
>>> In another test I do
>>>
>>> g.getRawGraph.query(new OSQLSynchQuery[ODocument]("select * from
>>> INDEX:V.testProperty where key = 'cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e'"))
>>>
>>> which takes 1 millisecond to return the vertex.
>>>
>>> Is the java graph query api really this slow or am I doing something
>>> wrong?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OrientDB" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to orient-database+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to a topic 

[orientdb] Re: Questions about ODB

[Nick DeYoung]

we also read this in our office for the first time yesterday and had the 
same reaction :)

How to win a race : cross the finish line first. 

thanks

On Sunday, May 31, 2015 at 12:27:11 AM UTC-7, scott molinari wrote:
>
> Hi,
>
> We are still evaluating Databases. MongoDB was looking good, and now we 
> like what OrientDB has to offer, since we will also be needing a graph 
> database and the ability to use a flexible schema database with it is like 
> a dream come true. However... 
>
> I noticed in some (a bit older) benchmarks, that ODB is on the slower end 
> of the performance scale compared to other document and graph data stores. 
> Is this due to the split it tries to make between the two types? Is there 
> promise that it will ever get as quick as the others? Or is the lack of 
> performance a compromise needed for having such a very flexible and yet 
> ACID compliant datastore?
>
> Do people using ODB still need some sort of caching, which is normal 
> practice with RDBMS, to take up slack in performance? 
>
> Do people using ODB, still need an indexing system, like Elasticsearch, to 
> take up slack in performance (when needing lots of indexing)?
>
> We are looking at a multi-tenant system and have decided, due to the 
> expressiveness of the system we are building, it would be much easier (and 
> safer) to just give each customer their own database. Some questions on 
> that.
>
> 1. Is the disk footprint of each ODB database relatively small? Does it do 
> anything like the disk pre-allocation stuff that MMap in MongoDB does?
> 2. Would a good number of databases mean the performance of an ODB 
> instance would be degraded at all? Let's assume the hardware and I/O can 
> handle the number of databases. Purely talking about ODB, would it start to 
> falter in anyway, because multiple databases are being used?
> 3. Is it a multi-threaded system?
>
> On other topics:
> 1. Does ODB have an issue with document size growing above allocation size 
> (if it has it) and any necessary movement of the data on disk like Mongo 
> has (with MMap)?
> 2. The bug tracking of ODM seems, well, like it isn't being done well. 
> This might be only my first impression. Can anyone expand on their 
> experience?
> 3. I tried to find documentation on it, but how does ODB handle network 
> partitioning? MongoDB can cause a client to read an inconsistent state and 
> even incorrect data (in a very tight time window), when there is a network 
> partition between replication nodes and during the continued spit. Does ODM 
> have any such similar issues?
>
> Thanks for any help on any questions in advance.
>
> Scott
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: What is the recommended way to manage OrientDB connections in Express.js or any web application

[Samuel Goldenbaum]

hmm, concerning

On Tuesday, June 2, 2015 at 4:33:25 PM UTC+2, André Marques wrote:
>
> I did some load tests using the connection pool and had some problems, I 
> don't think the connections are threadsafe, or is not stable.
> Using one connection for all requests didn't work well, looks like the 
> connection executes only one statement at time.
> Then I tested using one connection per request and the response time were 
> a lot better.
> I think that the connection per request is the best way right now.
> I'm new to orientdb, so I might be wrong.
>
> To close the connection you have to call the close() method
> var server = oriento({...});
> var db = server.use({...});
> ...
> server.close();
>
>
>
>
> On Tuesday, June 2, 2015 at 6:51:32 AM UTC-3, Samuel Goldenbaum wrote:
>>
>> thanks Andre
>>
>> From what I undertand Oriento will open a new connection as needed when 
>> you try to access the db - at what point is this connection closed? Are the 
>> connections threadsafe?
>>
>> On Monday, June 1, 2015 at 4:38:55 PM UTC+2, André Marques wrote:
>>>
>>> Hi,
>>>
>>> You can also use the connection pool:
>>>
>>> var server = Oriento({
>>>   host: 'localhost',
>>>   port: 2424,
>>>   username: 'root',
>>>   password: 'yourpassword',
>>>   pool: {
>>> max: 10
>>>   }
>>> });
>>>
>>>
>>> On Friday, May 29, 2015 at 4:12:27 AM UTC-3, Samuel Goldenbaum wrote:

 What is the recommended way to manage OrientDB connections in 
 Express.js or any web application for that matter? Connection per request? 
 Would be using the oriento Node.js driver.



-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] How fast should OrientGraph.query() be?

[Nick DeYoung]

Craig,

I have tried that, it takes 11 ms. but that is not a Pipe -
(g.getVertices())

our code base is leveraging another TinkerPop enabled graph databse and are
researching the idea of switching it out.

my research is trying to figure out how does orient perform on the generic
Tinkerpop API.
I want to do things like
g.V().has("someProperty","someValue").outE("someLabel")somemoreStepsInMyPipe..
and know that that is going to hit indexes.

Does it ?

this is a simple test of the different ways I am accessing the graph and
their timing on 300,000 vertices (not connected at the momen)

 time("orient graph api 'orient specific'") {
val v = g.getVertices("V.testProperty",
"cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e")

} 11 ms

time("tinkerpop pipeline 'generic'") {
  val v = new GremlinPipeline(g, true).V("testProperty",
"cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e").next()

} 21 seconds

time ("another blueprints? " ) {
  val v = g.query().has("testProperty",
"cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e").vertices()

} 19 seconds

time("sql count all 'orient specific'") {
  val v:OResultSet[ODocument] = g.getRawGraph.query(
new OSQLSynchQuery[ODocument]("select * from
INDEX:V.testProperty where key = 'cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e'")
  ) 1 ms


}

// throws an error in distrubuted mode
//time ("gremlin command 'generic' ") {
//  val r = g.getRawGraph.command(new
OCommandGremlin("g.V().has('testProperty')")).execute()
//}


If I understand Orient's documentation right, I am going to have to either
change our pipes (traversals in tinkerpop) into SQL+ queries in order to
leverage the claims of orient's speed.

If i'm wrong in this, let me know




On Mon, Jun 1, 2015 at 11:33 PM, W. Craig Trader 
wrote:

> Nick ...
>
> Much like you told the SQL engine to use an index (select * from
> INDEX:V.testProperty ...), you need to explicitly use indexes from the
> graph API, as follows:
>
> *Java:*
>
> OrientVertex result = g.getVertices( "V.testProperty", "
> cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e" ).iterator().next();
>
>
> *Gremlin:*
> GremlinPipeline p = g.getVertices( "V.testProperty", "
> cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e" )._()
>
>
> I think you'll find that using indexes with the Java API is even faster
> than the SQL query API.
> - Craig -
>
>
> On Mon, Jun 1, 2015 at 5:33 PM, Nick DeYoung 
> wrote:
>
>> I have an orient db 2.0.10 community server up and running
>> I have created a simple test where I have placed 300,000 vertices in an
>> orient database each with a property "testProperty" with a value -
>> UUID.randomUUID().toString
>> I have created an index on the property
>>
>>   graph.createKeyIndex("testProperty", classOf[Vertex])  // this is scala
>> :)
>>
>> In a  test I create an OrientGraph connected via remote:
>> 127.0.0.1:2424/test-database
>>
>> and do
>>
>> g.query().has("testProperty", "cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e")
>>
>> This takes 20 seconds to return the vertex with that UUID.
>>
>> In another test I do
>>
>> g.getRawGraph.query(new OSQLSynchQuery[ODocument]("select * from
>> INDEX:V.testProperty where key = 'cbc6b219-9df3-44c5-90b2-ab7a6bd9bf7e'"))
>>
>> which takes 1 millisecond to return the vertex.
>>
>> Is the java graph query api really this slow or am I doing something
>> wrong?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OrientDB" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to orient-database+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "OrientDB" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/orient-database/Ff5Fbxi6p20/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
// ndy

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: OrientDB ETL tool

[James Wang]

Thanks, Luigi.

More questions:  is it possible to speed up OETL speed please?

In remote mode, I can only  import about 200 vertices per second

Thanks a lot in advance

On Friday, 29 May 2015 12:18:31 UTC+1, James Wang wrote:
>
> Hi All,
>
> I am new to OrientDB and trying to import data from a CSV file using the 
> ETL tool.
>
> Do I need to stop the OrientDB server firstly please?
> Please help.
>
> Thanks a lot in advance
> James
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: Complex query

[Andrey Yesyev]

Someone!? Please?

On Monday, June 1, 2015 at 6:10:15 PM UTC-4, Andrey Yesyev wrote:
>
> Hi there,
>
> I need help with a query.
> My schema is pretty simple. Vertices are connected with Edges of type 
> RELATED which have property count.
> 2 vertices can have connection in both ways at the same time.
>
> V1--RELATED(count=17)-->V2
>
> V2--RELATED(count=3)-->V1
>
> I need to build a query that for vertex Vn, will find all vertices 
> connected with RELATED edge to this Vn and also, for each pair [Vn, Vx] 
> will calculate SUM of in_RELATED.count and out_RELATED.count.
>
> For that simple example above, this query result for V1 would be
>
> |  Vertex   |Count|
> ||
> |V2  |  20|
>
> Is it possible to do in one query at all?
>
> Any help is very much appreciated!
>
> -Andrey
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: Using a very large number of databases

[scott molinari]

Considering that any database must store data somewhere and that somewhere 
is always in the file system of the server, then it might be safe to say, 
there is certainly a limit, usually fixed by ulimit in the OS (Linux). I am 
also interested in the answer though.

Scott

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] How do I run multiple queries in Studio?

[isobretatel]

2.0.10

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: What is the recommended way to manage OrientDB connections in Express.js or any web application

[André Marques]

I did some load tests using the connection pool and had some problems, I 
don't think the connections are threadsafe, or is not stable.
Using one connection for all requests didn't work well, looks like the 
connection executes only one statement at time.
Then I tested using one connection per request and the response time were a 
lot better.
I think that the connection per request is the best way right now.
I'm new to orientdb, so I might be wrong.

To close the connection you have to call the close() method
var server = oriento({...});
var db = server.use({...});
...
server.close();




On Tuesday, June 2, 2015 at 6:51:32 AM UTC-3, Samuel Goldenbaum wrote:
>
> thanks Andre
>
> From what I undertand Oriento will open a new connection as needed when 
> you try to access the db - at what point is this connection closed? Are the 
> connections threadsafe?
>
> On Monday, June 1, 2015 at 4:38:55 PM UTC+2, André Marques wrote:
>>
>> Hi,
>>
>> You can also use the connection pool:
>>
>> var server = Oriento({
>>   host: 'localhost',
>>   port: 2424,
>>   username: 'root',
>>   password: 'yourpassword',
>>   pool: {
>> max: 10
>>   }
>> });
>>
>>
>> On Friday, May 29, 2015 at 4:12:27 AM UTC-3, Samuel Goldenbaum wrote:
>>>
>>> What is the recommended way to manage OrientDB connections in Express.js 
>>> or any web application for that matter? Connection per request? Would be 
>>> using the oriento Node.js driver.
>>>
>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Re: Questions about ODB

[scott molinari]

I've now read in the docs there is an option to do preallocation to 
basically pack on extra space for changing record sizes (through updates), 
in order to avoid movement of records. Is this still true? The 
documentation is a bit thin on explaining it.

Scott 

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] How do I run multiple queries in Studio?

[Enrico Risa]

Which version of OrientDB?

2015-06-01 21:04 GMT+02:00 isobretatel :

> I have many CREATE queries.
> How do I run multiple queries in Studio?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Re: Keep the database small?

[scott molinari]

You now have my interest peaked. That is very interesting to know. Since we 
will be holding metadata (like the schema/ mapping) about our data anyway, 
this means we can take advantage of the schema option and not storing field 
names. Cool.  

Now to just get more understanding about ODB's performance..

Scott

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Re: Keep the database small?

[Andrey Yesyev]

Hi Luca!
The only suggestion I have - add more examples.
I got back to OrientDB after more than a year break (it looks way better I
have to admit) and I still see a lack of documentation.
I'm struggling to build a query that returns edges' properties along with
vertices' ones and I can't find any examples on that.

Thanks!

-Andrey

On 2 June 2015 at 08:11, Luca Garulli  wrote:

> Hi guys,
> That piece of doc is old and... completely useless. Starting from 2.0
> field names aren't stored in documents anymore if you define them in
> schema. I'm going to update that section. Any suggestions is welcome.
>
> Best Regards,
>
> Luca Garulli
> CEO at Orient Technologies LTD
> the Company behind OrientDB
> http://about.me/luca.garulli
>
>
> On 2 June 2015 at 14:02, Andrey Yesyev  wrote:
>
>> I came across with this performance "tip" too.
>> I was also very surprised.
>>
>>
>> On Tuesday, June 2, 2015 at 3:37:21 AM UTC-4, scott molinari wrote:
>>>
>>> I am not sure if it is because the person writing doesn't speak English
>>> as the native language, but this can't be right
>>> ,
>>> as a performance tuning tip.
>>>
>>> *Keep the database small*
 The smaller the database you have, the bigger are the number of records
 you can cache in memory. Furthermore small database means faster seek in
 filesystem and minor loading time from disk/network. In order to keep your
 database small follow the following suggestions:
 *Keep field names short*
 OrientDB is schema-less that means field names are stored with the
 values too. So if you call a field "out" instead of "outVertices" you saves
 8 characters, namely 8 bytes per record. Applying this to millions of
 records allows you to save several Megabytes.
>>>
>>>
>>>  I understand about disk space savings with small field names, however,
>>> that is purely a userland decision and shouldn't have a large impact on
>>> overall database performance.
>>>
>>> So, is this really meant as a tip for performance tuning? Because, I
>>> thought OrientDB is also built for scale with large data sets.
>>>
>>> Scott
>>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OrientDB" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to orient-database+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "OrientDB" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/orient-database/t2o7HqcTg7s/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [orientdb] Re: Questions about ODB

[Luca Garulli]

Hi Scott,
We use another Issue Tracker for clients that is synchronized with GitHub.
Unfortunately GitHub issue tracker is quite limited.

To ask question this is the best place.

Best Regards,

Luca Garulli
CEO at Orient Technologies LTD
the Company behind OrientDB
http://about.me/luca.garulli


On 2 June 2015 at 06:30, scott molinari 
wrote:

> Ok. Been looking around Github and there is quite a lot of activity both
> from users and devs. That is good and answers my second question 2. It
> looks a bit chaotic though, which is I think an issue of a busy Github repo
> and not necessarily the management. So, maybe a better tracking system
> could come in handy?Or, push the users just asking questions to Gitter? Or
> Google Groups? So issues are actually bugs?
>
> Scott
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] OrientDB Eval

[Fabio Ricci]

Hi Luigi

excellent! I am looking forward to get your answers. Meanwhile I will
learn out of your daily valuable contributions in this mailing list

Regards
Fabio

Am 29.5.15 um 12:21 schrieb Luigi Dell'Aquila:
> Hi Fabio,
>
> Thanks for reaching out, I'll take a look at your questions and I'll
> be back with answers soon.
>
> Thanks
>
> Luigi
>
>
> 2015-05-29 10:52 GMT+02:00 Fabio Ricci  >:
>
> Dear OrientDB community
>
> thank you for helping in the first phases of my evaluation of
> OrientDB using RDF material / embedded so far. I hope my
> questions/issues could contribute to some improvements.
>
> I noted that fruitful exchanges are taking place all the time in
> this discussion group.
>
> This evaluation of OrientDB took alreay some time & resources to
> proceed, unfortunately there are some unacknowledged / unanswered
> questions/issues (attached) which caused the stop of (my) works in
> this direction.
>
> I will be pleased to resume the evaluation of OrientDB as soon as
> a dialogue will be some how resumed, wish you a nice work and
>
> a nice weekend
> Fabio
>
> Kind regards / Meilleures salutations / Freundliche Grüsse
> /Fabio Ricci/
> semweb
>
>   Semantic Web Technologies · Records Management
> Software systems · ICT coaching · ICT Projects leading
>
>   
>
> *www.semweb.ch* 
>
>   
>
>   
>
> Weinmanngasse 26
> CH-8700 Küsnacht ZH (Switzerland)
>
>   
>
>   
>
> /Tel./
>
>   
>
> +41 (076) 5281961 
> +39 (389) 0681334 
>
> /Skype:/
>
>   
>
> *semweb-llc* 
>
> *Confidentiality Warning*: This message and any attachments are
> intended only for the use of the intended recipients, are
> confidential and maybe privileged. If you are not the intended
> recipient, you are hereby notified that any review,
> retransmission, conversion to hard copy, copying, circulation or
> other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify
> the sender immediately by return email, and delete this message
> and any attachments from your system. Thank you.
>
>
> -- 
>
> ---
> You received this message because you are subscribed to the Google
> Groups "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to orient-database+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
>
> ---
> You received this message because you are subscribed to the Google
> Groups "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to orient-database+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [orientdb] Re: Keep the database small?

[Luca Garulli]

Hi guys,
That piece of doc is old and... completely useless. Starting from 2.0 field
names aren't stored in documents anymore if you define them in schema. I'm
going to update that section. Any suggestions is welcome.

Best Regards,

Luca Garulli
CEO at Orient Technologies LTD
the Company behind OrientDB
http://about.me/luca.garulli


On 2 June 2015 at 14:02, Andrey Yesyev  wrote:

> I came across with this performance "tip" too.
> I was also very surprised.
>
>
> On Tuesday, June 2, 2015 at 3:37:21 AM UTC-4, scott molinari wrote:
>>
>> I am not sure if it is because the person writing doesn't speak English
>> as the native language, but this can't be right
>> ,
>> as a performance tuning tip.
>>
>> *Keep the database small*
>>> The smaller the database you have, the bigger are the number of records
>>> you can cache in memory. Furthermore small database means faster seek in
>>> filesystem and minor loading time from disk/network. In order to keep your
>>> database small follow the following suggestions:
>>> *Keep field names short*
>>> OrientDB is schema-less that means field names are stored with the
>>> values too. So if you call a field "out" instead of "outVertices" you saves
>>> 8 characters, namely 8 bytes per record. Applying this to millions of
>>> records allows you to save several Megabytes.
>>
>>
>>  I understand about disk space savings with small field names, however,
>> that is purely a userland decision and shouldn't have a large impact on
>> overall database performance.
>>
>> So, is this really meant as a tip for performance tuning? Because, I
>> thought OrientDB is also built for scale with large data sets.
>>
>> Scott
>>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: Keep the database small?

[Andrey Yesyev]

I came across with this performance "tip" too.
I was also very surprised.

On Tuesday, June 2, 2015 at 3:37:21 AM UTC-4, scott molinari wrote:
>
> I am not sure if it is because the person writing doesn't speak English as 
> the native language, but this can't be right 
> ,
>  
> as a performance tuning tip.
>
> *Keep the database small*
>> The smaller the database you have, the bigger are the number of records 
>> you can cache in memory. Furthermore small database means faster seek in 
>> filesystem and minor loading time from disk/network. In order to keep your 
>> database small follow the following suggestions:
>> *Keep field names short*
>> OrientDB is schema-less that means field names are stored with the values 
>> too. So if you call a field "out" instead of "outVertices" you saves 8 
>> characters, namely 8 bytes per record. Applying this to millions of records 
>> allows you to save several Megabytes.
>
>
>  I understand about disk space savings with small field names, however, 
> that is purely a userland decision and shouldn't have a large impact on 
> overall database performance.
>
> So, is this really meant as a tip for performance tuning? Because, I 
> thought OrientDB is also built for scale with large data sets.
>
> Scott 
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Re: What is the recommended way to manage OrientDB connections in Express.js or any web application

[Samuel Goldenbaum]

thanks Andre

>From what I undertand Oriento will open a new connection as needed when you 
try to access the db - at what point is this connection closed? Are the 
connections threadsafe?

On Monday, June 1, 2015 at 4:38:55 PM UTC+2, André Marques wrote:
>
> Hi,
>
> You can also use the connection pool:
>
> var server = Oriento({
>   host: 'localhost',
>   port: 2424,
>   username: 'root',
>   password: 'yourpassword',
>   pool: {
> max: 10
>   }
> });
>
>
> On Friday, May 29, 2015 at 4:12:27 AM UTC-3, Samuel Goldenbaum wrote:
>>
>> What is the recommended way to manage OrientDB connections in Express.js 
>> or any web application for that matter? Connection per request? Would be 
>> using the oriento Node.js driver.
>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] addEdge() to a 'remote' vertex introduces OTransactionException?

[Clark Peng]

Hi all,

I'm having issue while using OrientVertex.addEdge() API.
My orientdb version is community 2.0.10 and it runs as distributed mode.

The distributed-config.json has below configurations.

"clusters":{
...
"vertex1_server1":{ "servers":["server1"]}
"edge1_server1"  :{ "servers":["server1"]}
"vertex2_server2":{ "servers":["server2"]}
...
}

That means:
1. cluster "vertex1_server1" and "edge1_server1" will only reside in server1
2. cluster "vertex2_server2"  will only reside in server2

Now when I wish to add vertex from cluster "vertex1_server1" to cluster 
"vertex2_server2", it always throws below exception.

"ErrorType:[com.orientechnologies.orient.core.exception.OTransactionException] 
Msg:Error on committing distributed transaction"

If I change distributed-config.json to have all clusters on all servers, 
then the program executes as expected.

"clusters":{
...
"vertex1_server1":{ "servers":["server1", "server2", ""]}
"edge1_server1"  :{ "servers":["server1", "server2", ""]}
"vertex2_server2":{ "servers":["server1", "server2", ""]}
...
}

So, my question is that, is it possible to add an edge that links to some 
vertex that's not reside in local clusters?
It seems not work in my environment and I'm not sure if it's due to wrong 
configuration or it's current limitation?

Thanks,
Clark

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[orientdb] Keep the database small?

[scott molinari]

I am not sure if it is because the person writing doesn't speak English as 
the native language, but this can't be right 
,
 
as a performance tuning tip.

*Keep the database small*
> The smaller the database you have, the bigger are the number of records 
> you can cache in memory. Furthermore small database means faster seek in 
> filesystem and minor loading time from disk/network. In order to keep your 
> database small follow the following suggestions:
> *Keep field names short*
> OrientDB is schema-less that means field names are stored with the values 
> too. So if you call a field "out" instead of "outVertices" you saves 8 
> characters, namely 8 bytes per record. Applying this to millions of records 
> allows you to save several Megabytes.


 I understand about disk space savings with small field names, however, 
that is purely a userland decision and shouldn't have a large impact on 
overall database performance.

So, is this really meant as a tip for performance tuning? Because, I 
thought OrientDB is also built for scale with large data sets.

Scott 

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.