Hi everyone We are using OrientDB like mongodb for some properties and it is working very well but we need to index some keys of the document (considering JSON). Please, what is the type of a property that stores a json object with many levels nested? Thanks in advance Best regards André
On 6 Jan 2017 06:24, <[email protected]> wrote: [email protected] <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/orient-database/topics> Google Groups <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> Topic digest View all topics <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/orient-database/topics> - Proper way to generate and insert data into OrientDB <#m_4313801924897894530_group_thread_0> - 2 Updates - Kotlin <#m_4313801924897894530_group_thread_1> - 1 Update - Reached maximum number of concurrent connections <#m_4313801924897894530_group_thread_2> - 1 Update Proper way to generate and insert data into OrientDB <http://groups.google.com/group/orient-database/t/847440ecf0235c40?utm_source=digest&utm_medium=email> Cyprien Gottstein <[email protected]>: Jan 05 06:44AM -0800 Hi, The scripts are in java, those are not batches, and we didn't wanted to post it online to be perfectly honest. But. Great news, problem solved ! I remembered something crucial, it's mainly me who is working on the subject and at first i wanted to run the OrientDB server on my own local machine. Since my computer is not what i would call young and powerful, i asked to make it run on a virtual machine in our own datacenter. I work in France. The Datacenter is in Poland. What was it again ? Non-Transactionnal Mode means " for every new entity we write it immediately on disk ", it meant for every entry we were eating the latency between our building in France and the datacenter in Poland. We made a proper uber-jar to run the generation code on the very same machine holding the Orient DB server's instance. We did some simple benchmark to check how the total execution time would behave depending on the transaction mode and location of the program. Job Place - Transactionnal : 900 secs (i don't have the real number, i just know its around that, sorry.) Job Place - Non-Transactionnal : more than 54000 secs Datacenter - Transactionnal : 212 secs Datacenter - Non-Transactionnal : 2700 secs (i don't have the real number, i just know its around that, sorry.) So thanks to executing the code from the right place we avoided some HUGE loss of times. The Non-Transactionnal mode is slower but your promess was kept, it runs with a constant amount of RAM, that means if we want to generate 10 millions or even 50 millions of entities we can in a reasonnable time so i would guess it's fine. Last question and i think this case will be closed (at least for me) : The OrientDB Documentation warns in http://orientdb.com/docs/last/Performance-Tuning.html#wise- use-of-transactions that : "Transactions slow down massive inserts unless you're using a "remote" > connection. In that case it speeds up all the insertion because the > client/server communication happens only at commit time." We can indeed see it in effect when we run our little benchmark (Transactionnal - 212 VS Non-Transactionnal 2700) , are we in a difference of speed that is to be expected ? Or does something still feels off ? Thanks again for your time, Cyprien Gottstein Luca Garulli <[email protected]>: Jan 05 11:06PM +0100 Hi Cyprien, Glad you solved it. With remote and/or graph operations, specially when you add multiple edges, transaction always help. Before 2.2 transactions didn't run in parallel, but after 2.2 they can. In facts, this is my next question. Are you running on multiple threads? Best Regards, Luca Garulli Founder & CEO OrientDB LTD <http://orientdb.com/> On 5 January 2017 at 15:44, Cyprien Gottstein <[email protected]> wrote: Back to top <#m_4313801924897894530_digest_top> Kotlin <http://groups.google.com/group/orient-database/t/e38fc28e7c2b1402?utm_source=digest&utm_medium=email> Roberto Franchini <[email protected]>: Jan 05 12:26PM > The classic issue is that of parameterless constructors. > If there is demand for this, perhaps with some guidance, I could write and > share a binding module? I'm playing with Kotlin and OrientDB, but with the plain graph or document api. I guess you're talking about the object api. Can you share some examples? -- Best regards, Roberto Franchini OrientDB LTD - http://orientdb.com Back to top <#m_4313801924897894530_digest_top> Reached maximum number of concurrent connections <http://groups.google.com/group/orient-database/t/88aa696b03298aeb?utm_source=digest&utm_medium=email> Claudio Massi <[email protected]>: Jan 05 03:24AM -0800 This is a sample multithreaded java code (not scala) which fails with "No more resources available in pool" if you do not use db.close() import com.orientechnologies.orient.core.db.document.ODatabaseDocumentPool; import com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx; import com.orientechnologies.orient.core.record.impl.ODocument; import com.orientechnologies.orient.core.sql.query.OSQLSynchQuery; public class ThreadExample { private static final OSQLSynchQuery query = new OSQLSynchQuery("SELECT FROM V"); public static void main(String[] args) { for (int i = 0; i < 100; i++) { new Thread("" + i) { public void run() { // ODatabaseDocumentTx db = new ODatabaseDocumentTx("remote:localhost/GratefulDeadConcerts").open("admin", "admin"); // or use pool ODatabaseDocumentTx db = ODatabaseDocumentPool.global(1,40).acquire("remote:localhost/GratefulDeadConcerts", "admin", "admin"); System.out.println(" 1 -- Thread: " + getName() + " running"); db.query(query); // db.close(); // if you do not close it will fail with : No more resources available in pool (max=40) try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } } }.start(); } } } com.orientechnologies.common.concur.lock.OLockException: No more resources available in pool (max=40). Requested resource: remote:localhost/GratefulDeadConcerts at com.orientechnologies.common.concur.resource.OResourcePool. getResource(OResourcePool.java:70) at com.orientechnologies.common.concur.resource.OReentrantResourcePool. getResource(OReentrantResourcePool.java:84) at com.orientechnologies.orient.core.db.ODatabasePoolAbstract. acquire(ODatabasePoolAbstract.java:158) at com.orientechnologies.orient.core.db.ODatabasePoolAbstract. acquire(ODatabasePoolAbstract.java:138) at com.orientechnologies.orient.core.db.ODatabasePoolBase. acquire(ODatabasePoolBase.java:128) at ThreadExample$1.run(ThreadExample.java:22) Il giorno mercoledì 4 gennaio 2017 15:19:46 UTC+1, [email protected] ha scritto: Back to top <#m_4313801924897894530_digest_top> You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/orient-database/join> . To unsubscribe from this group and stop receiving emails from it send an email to [email protected]. -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
