1 Reply Latest reply: May 15, 2014 2:29 PM by Linda Lee-Oracle RSS

    ONDB 3.0.5 vs RDBMS 11gR2 :  put/insert performance comparison





      My company stores network sensors data in a 11gr2 database.

      These data are inserted with bulk inserts with Direct-Path ( /*+APPEND_VALUES*/ hint).




      Since I heard about ONDB, I wished to make a quick&dirty test between both db.



      I tried to compare this insert performance with Put method from a ONDB 3.0.5.



      I used the same platform : win7 / 8-cores / 16 GB RAM / 500GB SSD


      My test store has only 1 node with capacity set to 1.


      For testing purpose, I try to insert/put a 10k rows at a time.



      On the 11g RDBMS, I use the following test case :



         type tdv7_tab is table of TWTDV7%ROWTYPE;

         tdv7 tdv7_tab;


         select TIMEID,





        BULK COLLECT into tdv7

         from TWTDV7_INPUT;


         forall i in tdv7.first .. tdv7.last


        INTO TWTDV7








         values (tdv7(i).TIMEID,tdv7(i).INSID,tdv7(i).INDID,tdv7(i).FLAG, tdv7(i).VALUE );






             NOTE : TWTDV7_INPUT contains 10k rows and TWTDV7 has a PK on ( INSID,INDID,TIMEID)



      On ONDB 3.0.5, I use the following testcase (tableAPI used) :


              Durability defaultDurability =

              new Durability(Durability.SyncPolicy.NO_SYNC, // Master sync

              Durability.SyncPolicy.NO_SYNC, // Replica sync



        int lOpCount = 0;

        int lMaxOpCount = 10000;


            while ( lOpCount++<= lMaxOpCount ) {

                row.put("INSID", 2l);

                row.put("INDID", 1l);

                row.put("DR", 7);

                row.put("TIMEID", 1215412l + lOpCount );

                row.put("VALUE", 100.2 + lOpCount);

                opList.add(tof.createPut(row, null, true));



            try {

            a = System.currentTimeMillis();

            tableH.execute(opList, new WriteOptions(defaultDurability, 0, null));

            b = System.currentTimeMillis();


            System.out.println("duration=>" + (b-a) +" ms");



                 NOTE : key is /INSID/INDID/DR/-/TIMEID, value is VALUE.




      Roughly, the elapsed time (avg on 100 runs) are the following


      RDBMS : about 56ms (includes commit)

      ONDB : about 106ms


      As you can see, ONDB put is twice slower then the RDBMS insert.


      My question are :

      • Is this test relevant ?
      • how to improve the ONDB put performance  ?
      • Are there some JVM parameters to tweak  ?



      Thanks in advance.




        • 1. Re: ONDB 3.0.5 vs RDBMS 11gR2 :  put/insert performance comparison
          Linda Lee-Oracle



          A couple of things come to mind about your experiment.


          We've never compared the bulk insert path into the Oracle RDBMS to NoSQL inserts because we don't have a true bulk insert mechanism yet. We've focused initially on general purpose, finer granularity operations. Using the execute function to group a number of NoSQL DB operations optimizes the network communications cost, but on the NoSQL DB server side, the operations are done individually. A more apples to apples approach would be to compare the cost of non-bulk insert operations, but if your application finds the bulk insert model suitable, then it makes sense to do the comparison that you are doing. We would like to have a bulk insert in the future.


          Our focus has been on providing horizontal scalability, so our performance efforts are generally based on benchmarks with larger data sets. We do find that smaller benchmarks need evaluation to determine whether one is seeing true server side performance, or whether a client side test issue is dominant. The Admin Guide and FAQ mention the server side <storename>.perf files, which show per-node performance metrics, and that can be a useful first step to get a sense for performance. For example, we have found that an insufficient number of clients can be a gating factor when driving a large benchmark.


          Do keep in mind that the single KVLite instance is not meant to be a performance tool. In particular, the cache size is small for that instance. The capacity sizing guide at the end of the Admin Guide provides a comprehensive look at the performance factors to consider, but in general, if I had to guess with no context, cache sizing at the replication nodes is often one of the first parameters to tune. This FAQ entry FAQ - Oracle NoSQL Database

          talks about how to use the memory_mb parameter for the Storage Nodes to set cache sizes. But it's just a guess whether that is the first factor!