← Back to team overview

maria-discuss team mailing list archive

Re: Performace issue with insert

 

The only time an innodb table is broken is if the computer lost writes to
the system or the media is corrupted.  InnoDB is fully transactional.  If
you had similar problems and MyISAM "works" it will likely have bad data in
it, because myisam has no checksums.  MyISAM is the kiss of death, it is
old, not really supported, it has concurrency problems and it is unreliable
after a crash without a lengthy repair.

--Justin

On Sun, Jan 31, 2016 at 2:44 PM, walter harms <wharms@xxxxxx> wrote:

>
>
> Am 31.01.2016 09:09, schrieb Sergei Golubchik:
> > Hi, Reindl!
> >
> > On Jan 30, Reindl Harald wrote:
> >>
> >>
> >> Am 30.01.2016 um 21:07 schrieb walter harms:
> >>> Aktualy I do now some profiling now we want to see the differences
> >>> when switching 31-1.  We used myISAM since the biggest problem is
> >>> speed and immoDB showed to be crash sensitive.  We store long time
> >>> series data so the system is writing data all the time.
> >>
> >> for "writing data all the time" MyISAM is for sure a completly wrong
> >> decision because the performance strength of MyISAM was always on
> >> most-read workloads
> >>
> >> MyISAM *always* does a *complete table lock* for writes and don't allow
> >> concurrent writes without locking - that don't scale when you write all
> >> day long and there are table locks all day long
> >
> > MyISAM should perform very good if inserts are *append only* (no updates
> > or deletes). In this case MyISAM will not use an exclusive table lock
> > and concurrent reads will be allowed.
> >
> > It is typical for some kind of logging - one threads inserts *all the
> > time* other threads are reading the data concurrently.
> >
> > In fact, this is one of the use cases MyISAM was written for.
> >
>
>
> This is was we actualy do with, never delete, very few updates and read is
> no performance problem.
>
> "crash sensitive" translates into: We had 3-4 occassions where an full
> backup was
> needed, and all had all to do with immoDB tables broken beyond repair.
>
>
> re,
>  wh
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-discuss
> Post to     : maria-discuss@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-discuss
> More help   : https://help.launchpad.net/ListHelp
>

References