I think InnoDB has improved a lot since Oracle aquired MySQL. We could default to InnoDB again.
Sebastian 2012/9/23 Maxim Solodovnik <[email protected]>: > correction: > InnoDB results: > initial lang import == 56 sec; subsequent import == 0/1 sec (Empty > dropped/created DB) > initial lang import == 3 sec; subsequent import == 0/1 sec (Values were > re-added to existent DB) > > > > On Sun, Sep 23, 2012 at 1:32 PM, Maxim Solodovnik <[email protected]> > wrote: >> >> Hello Sebastian, >> >> <property name="openjpa.jdbc.DBDictionary" >> value="batchLimit=100,tableType=myisam"/> >> was added to mysql_persistence.xml to speed up things. >> While Vasily did migration from Hibernate to JPA he report the performance >> degradation. >> I did investigate this and found this is because of InnoDB used by >> default. >> >> Initial language import was significally slower. >> >> My current results are >> MyISAM: initial lang import == 9 sec; subsequent import == 0/1 sec >> InnoDB: initial lang import == 3 sec; subsequent import == 0/1 sec >> >> was measured with >> ./admin.sh -l >> >> Surprisingly right now InnoDB was faster, can you recheck these results on >> your machines? >> >> I would vote for hard delete of everything or add option to restore/purge >> deleted things. >> Currently it will be hard to implement cascade delete since our object >> structure is not good for it (all object need to have references to >> connected entities, we have "Long ref_id" instead :( ) >> >> >> On Sat, Sep 22, 2012 at 3:24 PM, [email protected] >> <[email protected]> wrote: >>> >>> Hi Maxim, >>> >>> I saw your last commit, still studying it :) >>> >>> One thing we might should consider is using InnoDB as default, as it >>> supports foreign key constraints. >>> For example the delete Organisation cannot work, there are references >>> in the table "rooms_organisation". >>> While we are currently using MyISAM we do not recognizes it, if >>> switching to InnoDB or Postgres you migth immediately see that it does >>> not work. >>> >>> We might also discuss which of the tables we are going to actually >>> really delete and which ones we only flag as deleted. >>> I think organizations can be deleted "Hard". >>> Further "Hard delete": configurations, ldapconfigs, servers >>> But it will not work for users, rooms. >>> It might makes sense to argue that rooms should be deletable to free >>> up server space cause a deleted room has assigned room files that you >>> might want to get rid of to free your disk. However there are also so >>> many other referenced tables with records that should not be deleted >>> at all when deleting a room record so that I doubt that it makes sense >>> to put time into this complexity now. >>> >>> What do you think? >>> >>> Sebastian >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> [email protected] >> >> >> >> >> -- >> WBR >> Maxim aka solomax > > > > > -- > WBR > Maxim aka solomax -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
