Hello, what are main points to improve performance?
On Wednesday, February 11, 2015 at 4:05:39 AM UTC+5:30, Viktor Alexandrov wrote: > > Hi all! > > I'd like to begin using OrientDB in a project that needs to hold some > amount on data in a distributed (elastic) database. The amount is about > 200-500 GB of data. We need consistency, low latency, high throughput (up > to 30000 updates/s). At the moment we use Couchbase as our (document) DB, > set up on dedicated servers. But we have problems with consistency on one > Couchbase node failure (lost data), plus some stability problems with java > client and no ability to perform bulletproof real-time selects (Couchbase > needs time to update indexes - views - upon document addition/modification > of a document). Going back to SQL DB is no way (because of app > architecture). > > There are my questions: > > 1. Is OrientDB suitable as reliable distributed mode database with > synchronous replication? As I see the distribution part is done via > Hazelcast, which I'm pretty familiar with, so I think it should work OK. > 2. Does OrientDB implement real-time (rebuilt-upon-update) indexes, so if > I insert a new doc (vertex?) to DB it could be seen in "select * from > myClass" right in the next query? > 3. Does java client for OrientDB implement scrolling on large "result-set" > when, for example, querying half a million of records? > 4. What's going on with the scroll-select when a new item is inserted in > DB while result-set is not iterated to the end? (E.g. in Oracle we have a > snapshot and isolated transactions, in Couchbase we could see a removed doc > in query, and also see an added doc in query, depends on how lucky the > thread is). > 5. Deployment considerations - which is the best for > performance/fault-tolerance (especially restoring after failure): > a. Deploy a dedicated set of servers for OrientDB, use "remote" to > connect clients to db > b. Deploy a DB in the client set up on an application server (actually > JBoss AS7), so every client use "plocal" as storage and app-servers form > the DB cluster also, so we could use "fully-elastic" architecture: in case > of TPS raises we just add a new app-server which handle business-requests > and database requests. > > In both cases the whole cluster is suited in one data-center. > > Thanks for explanations 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
