| Subject | Re: [Firebird-Architect] One way to scale Firebird put it on memory virtual disk or ramfs |
|---|---|
| Author | Jim Starkey |
| Post date | 2013-01-22T20:11:17Z |
On 1/22/13 11:48 AM, Thomas Steinmaurer wrote:
consistent with the pico-second that it started plus whatever updates it
might have done. The degree of durability is up to the DBA, giving
control over the number of storage manages that must respond to a
pre-commit and whether or not a storage manager has to have all
transaction updates on persistent storage before acknowledging a commit.
At the physical level, NuoDB is eventually consistent. But from a
transaction perspective (the only way to view a database), it is fully
consistent.
The wrinkle, however, is that a transaction only sees those transactions
that have been reported as committed on that transaction's node. A
transaction committed on a different edge of the universe that hasn't
been reported as committed is view as concurrent. While
counter-intuitive, this isn't a problem.
rather than updating disk pages, NuoDB broadcasts replication messages.
Again, like Firebird, the engine knows to skip over record versions for
transactions that weren't (reported as) committed when the active
transaction started. Finally, like Firebird, the NuoDB engine
recognizes potential update conflicts at verb time, waiting for the
conflicting transaction to complete. Unlike Firebird, however, NuoDB
uses "atom" "chairman" to detect and resolve update conflicts.
There are many differences from Firebird:
* NuoDB is organized around "atoms" (distributed objects) rather than
disk pages
* Persistent storage is managed by storage managers rather than the
SQL engine
* The database engine is natively SQL / JDBC rather than BLR / OSRI.
* There is no lock manager
>A NuoDB transaction is fully ACID. It sees a view of the database
> Hope you don't mind two questions on NuoDB:
>
> * Is NuoDB fully solving the CAP theorem for distributed environments?
> Or e.g. is it eventually consistent when reading data?
>
consistent with the pico-second that it started plus whatever updates it
might have done. The degree of durability is up to the DBA, giving
control over the number of storage manages that must respond to a
pre-commit and whether or not a storage manager has to have all
transaction updates on persistent storage before acknowledging a commit.
At the physical level, NuoDB is eventually consistent. But from a
transaction perspective (the only way to view a database), it is fully
consistent.
The wrinkle, however, is that a transaction only sees those transactions
that have been reported as committed on that transaction's node. A
transaction committed on a different edge of the universe that hasn't
been reported as committed is view as concurrent. While
counter-intuitive, this isn't a problem.
>Logically, it isn't that much different from Firebird, except that
> * How does the asynchronous replication approach (if I got that right?)
> in NuoDB with the nature of synchronous JDBC calls, e.g. executeUpdate
> blocks until it's finished etc.
>
rather than updating disk pages, NuoDB broadcasts replication messages.
Again, like Firebird, the engine knows to skip over record versions for
transactions that weren't (reported as) committed when the active
transaction started. Finally, like Firebird, the NuoDB engine
recognizes potential update conflicts at verb time, waiting for the
conflicting transaction to complete. Unlike Firebird, however, NuoDB
uses "atom" "chairman" to detect and resolve update conflicts.
There are many differences from Firebird:
* NuoDB is organized around "atoms" (distributed objects) rather than
disk pages
* Persistent storage is managed by storage managers rather than the
SQL engine
* The database engine is natively SQL / JDBC rather than BLR / OSRI.
* There is no lock manager
>[Non-text portions of this message have been removed]
> Thanks,
> Thomas
>
> > On 1/22/13 9:35 AM, Dalton Calford wrote:
> >>
> >>
> >>
> >> *The only way to become fully ACID compliant is to house multiple
> >> servers,**
> >> **in multiple nocs, with queries being run atomically upon multiple
> >> systems**
> >> **in parallel so that if one system fails while processing work, the**
> >> **secondary system can respond as it has already been doing the same
> >> work as**
> >> **the primary. * The clients and tiers need to be able to determine
> if the
> >> answer they are getting is authoritative or non-authoritative. They
> need
> >> to be able to deal with multiple responses to the same query and
> all work
> >> is queue'd locally in case the entire local work process needs to be
> >> re-applied (either immediately or delayed due to network
> latency/drops).
> >>
> >> It is a very complex subject that involves the design of the pop, the
> >> power
> >> for the pop, the full system redundancy for each cluster, with full
> drive
> >> redundancy in the sans, with the client software and middle tier
> software
> >> designed to handle a complete system failure and switch-over to a
> totally
> >> different pop in a different city/province/country if needed.
> >>
> >> Ram drives work, but I normally use them for the temp drive. The
> >> benefits of ram drives depend upon the version of firebird, the
> version of
> >> the OS and the hardware parameters.
> >>
> >> If firebird is proposing going down that route, they would need to
> >> implement some new structures in Firebird, mirroring some of the
> elements
> >> that oracle and other database platforms have created.
> >>
> >> On 22 January 2013 08:51, Roman Simakov roman.simakov@...
> <mailto:roman.simakov%40red-soft.biz>
> >> > wrote:
> >>
> >>> **
> >>>
> >>>
> >>> 2013/1/22 Sergey Mereutsa serj@...
> <mailto:serj%40dqteam.com> >:
> >>>
> >>>> Hello Alex,
> >>>>
> >>>> and without shadow ACID rule has effect too - RAM-drive is the same
> >>> block device as usual HDD - until power is not lost :)
> >>>
> >>> In this case you have ACI but have no D.
> >>>
> >>>
> >>>
> >>
>
>