[Java/SQL] Sequoia - Wie gebruikt het echt?

[Verwijderd]

Ik zit al tijdenlang de ontwikkeling van Sequoia te volgen (voorgeen C-JDBC). Dit is een middle-ware oplossing die zorgt voor transparente clustering van generieke DBs. In principe kun je elk type DB in je cluster zetten (in theorie zelfs van verschillende merken, maar dat lijkt me echt vragen om problemen). Sequoia zelf benader je gewoon alsof het 1 DB is via een standaard JDBC driver.

Het punt is dat er in het verleden altijd dingetjes fout gingen. Zo parsed Sequoia bijvoorbeeld de SQL text die je erheen stuurt. Dit gebeurd om te kijken of het een update of select query is. Als de query echter met een comment begint, dan kan de parser hier niet om gaan en faalt de query. Ik heb dit in de source code opgezocht, en je ziet gewoon dat er keihard wordt gechecked of de eerste karakters "update", "select' etc zijn.

De andere keer is er weer een datatype dat in DB als een varchar voorkomt, en waar Sequoia perse een integer van maakt omdat een vorige query dezelfde kolom naam had, en het daar wel een integer was.

Door dergelijke 'kleine' dingetjes lukt het dus telkens niet om Sequoia echt te gaan gebruiken. Ik kan me echter moeilijk voorstellen dat dergelijke problemen voor andere mensen geen probleem zijn, en dus eigenlijk ook niet dat Sequoia door iemand al echt in de praktijk op een produktie server gebruikt wordt.

Is er hier toch iemand die Sequoia al eens -echt- gebruikt heeft?

[JKVA]

Kunnen database aanbieders, zoals Oracle, niet veel beter clustering realiseren voor hun eigen producten dan zo'n generieke Java oplossing?
Ik bedoel, het idee is leuk, maar ik zou er zelf niet zomaar aan beginnen, zeker aangezien ik de database in de meeste systemen als het meest kritische onderdeel beschouw.

[flowerp]

JKVA schreef op dinsdag 15 augustus 2006 @ 08:14:
Kunnen database aanbieders, zoals Oracle, niet veel beter clustering realiseren voor hun eigen producten dan zo'n generieke Java oplossing?

Dat is natuurlijk waar, maar niet iedereen heeft de $$$ of €€€ voor Oracle. Anderen gebruiken mischien uit andere dan financiele overwegingen een DB als bijvoorbeeld postgresql, die opzich uitstekend is maar helaas geen native clustering biedt.

Maar wordt hier eigenlijk niet gesteld dat het Sequoia project kwa concept eigenlijk volledig de plank misslaat? Er wordt zoals TS stelt inderdaad al jaren aan gewerkt, waarbij ook universiteiten mee doen. Als het hele concept 'flawed' was, zou men hier dan echt jaren mee doorgaan?

[ACM]

flowerp schreef op dinsdag 15 augustus 2006 @ 21:00:
Dat is natuurlijk waar, maar niet iedereen heeft de $$$ of €€€ voor Oracle. Anderen gebruiken mischien uit andere dan financiele overwegingen een DB als bijvoorbeeld postgresql, die opzich uitstekend is maar helaas geen native clustering biedt.

Native niet, maar er zijn wel een paar al-dan-niet commerciele oplossingen (o.a. Slony-1, de de facto standaard nu voor postgresql).

Maar wordt hier eigenlijk niet gesteld dat het Sequoia project kwa concept eigenlijk volledig de plank misslaat? Er wordt zoals TS stelt inderdaad al jaren aan gewerkt, waarbij ook universiteiten mee doen. Als het hele concept 'flawed' was, zou men hier dan echt jaren mee doorgaan?

Kwa concept is het op zich best aardig. Het zal met een beetje kennis prima als "poor man's replication" kunnen werken. Nadeel is echter dat zoiets natuurlijk geen uitgebreide ondersteuning kent voor synchronisatie na dat een master/slave uitgevallen is.
En blijkbaar heeft het nogal problemen met het parsen van SQL want ook iets als: (SELECT ... UNION ...) ORDER BY ... zal dus mis gaan en een SELECT ... FOR UPDATE zal niet helemaal geweldig uitgevoerd worden (wellicht zelfs op een andere host dan de daarop volgende update?).

Ik denk echter wel dat het technisch te lastig is om op dat niveau een echt werkende replicatie op te zetten, althans, niet een die bestand is tegen server-uitval. Wel een die met name read-queries load balanced over meerdere equivalente servers.

[flowerp]

ACM schreef op dinsdag 15 augustus 2006 @ 21:25:
[...]

Native niet, maar er zijn wel een paar al-dan-niet commerciele oplossingen (o.a. Slony-1, de de facto standaard nu voor postgresql).

Slony zat ik ook naar te kijken. Het is vanaf de homepage niet helemaal duidelijk of dat wel production ready is eigenlijk.

Kwa concept is het op zich best aardig. Het zal met een beetje kennis prima als "poor man's replication" kunnen werken. Nadeel is echter dat zoiets natuurlijk geen uitgebreide ondersteuning kent voor synchronisatie na dat een master/slave uitgevallen is.

Volgens mij juist wel. Dat is 1 van de speerpunten van Sequoia. Je kunt een DB weghalen uit het cluster (door bv hard de machine uit te zetten), en als je hem dan weer aanmeldt, wordt ie volledig automatisch weer in het cluster opgenomen. Writes die ondertussen gebeurd zijn worden eerst gereplayed, en als de nieuw aangemelde DB weer helemaal up to date is, doet ie weer volledig mee.

Ik heb dit zelf getest met enkele DBs, en dit werkt inderdaad. Scriptje gedraait die een zootje writes op het cluster afvuurt, terwijl er ondertussen ook constant read queries gedaan worden. Dan zomaar even een machine uit zetten en even later weer aan. Werkte perfect. Na het synchen was de machine die down ging weer helemaal identiek aan de anderen in het cluster.

Het zijn die knullige dingetjes die ook bij ons fout gaan. Het moeilijkste deel doet ie goed (was vroeger trouwens niet zo!), maar zoiets lulligs als een query met een comment beginnen loopt ie op vast.

En blijkbaar heeft het nogal problemen met het parsen van SQL want ook iets als: (SELECT ... UNION ...) ORDER BY ... zal dus mis gaan

Wat is er zo bijzonder aan een select ... union? Waarom zou een cluster hier potentieel problemen mee hebben?

[Verwijderd]

flowerp schreef op dinsdag 15 augustus 2006 @ 21:46:
[...]

Wat is er zo bijzonder aan een select ... union? Waarom zou een cluster hier potentieel problemen mee hebben?

Omdat de begin-karakters dan niet 'select' zijn, maar '(select'.

[flowerp]

Verwijderd schreef op dinsdag 15 augustus 2006 @ 21:55:
[...]

Omdat de begin-karakters dan niet 'select' zijn, maar '(select'.

Ahja, natuurlijk

[Verwijderd]

Ehmm... Hoort een SQL statement niet te beginnen met een commando (select, insert, update, delete, exec, etc.) en niet met een "haakje openen"? Dat was volgens mij in de SQL '89 standaard wel zo.
Zo ja, dan lijkt 't me niet dat Sequoia daar zo gek veel rekening mee hoeft te houden.

[flowerp]

Verwijderd schreef op dinsdag 15 augustus 2006 @ 23:44:
Ehmm... Hoort een SQL statement niet te beginnen met een commando (select, insert, update, delete, exec, etc.) en niet met een "haakje openen"? Dat was volgens mij in de SQL '89 standaard wel zo.

Dat dacht ik eigenlijk ook al. Ik weet wel dat in postgresql volgens mij in zo'n geval waar je haakjes nodig hebt altijd select * er voor zet.

Maar mischien dat in een andere DBMS het wel legaal is?

Zo ja, dan lijkt 't me niet dat Sequoia daar zo gek veel rekening mee hoeft te houden.

Blijft natuurlijk het issue over het commentaar staan. Elke parser (lexer onderdeel ervan) hoort in een text stream zowieso de commentaar eerst te strippen. Maar goed, dat is een slordigheidje en doet eigenlijk niet af aan het concept van Sequoia zelf.

[ACM]

flowerp schreef op dinsdag 15 augustus 2006 @ 21:46:
Slony zat ik ook naar te kijken. Het is vanaf de homepage niet helemaal duidelijk of dat wel production ready is eigenlijk.

Voor zover ik weet wel, maar heb het zelf nooit getest.

Volgens mij juist wel. Dat is 1 van de speerpunten van Sequoia. Je kunt een DB weghalen uit het cluster (door bv hard de machine uit te zetten), en als je hem dan weer aanmeldt, wordt ie volledig automatisch weer in het cluster opgenomen. Writes die ondertussen gebeurd zijn worden eerst gereplayed, en als de nieuw aangemelde DB weer helemaal up to date is, doet ie weer volledig mee.

Ah ok, ik heb nog te veel C-JDBC in mijn hoofd. Buiten de standaard vervelende dingetjes (random's, current_timestamp's etc) werkt het dan al beter dan ik dacht.

Wat is er zo bijzonder aan een select ... union? Waarom zou een cluster hier potentieel problemen mee hebben?

Een cluster zou er geen probleem mee moeten hebben, maar die parser van Sequoia wellicht wel

Verwijderd schreef op dinsdag 15 augustus 2006 @ 23:44:
Ehmm... Hoort een SQL statement niet te beginnen met een commando (select, insert, update, delete, exec, etc.) en niet met een "haakje openen"? Dat was volgens mij in de SQL '89 standaard wel zo.
Zo ja, dan lijkt 't me niet dat Sequoia daar zo gek veel rekening mee hoeft te houden.

Vziw is dat gewoon correcte SQL. Hoe wil je anders het resultaat van een union sorteren, zonder nog weer met subqueries te klooien?

In SQL '03 heet het een "<direct select statement: multiple rows>", maar in '99 kan ik het zo snel niet terug vinden (wat een hoop onleesbare tekst ook ) en die is ruwweg zo gespecificeerd in SQL '03:

<direct select statement: multiple rows> ::= <cursor specification>

<cursor specification> ::= <query expression> [ <order by clause> ] ...

<query expression> ::= ... <query expression body>

<query expression body> ::=
      <query term>
      | <query expression body> UNION [ ALL | DISTINCT ]
...

<query term> ::=
      <query primary>
...

<query primary> ::=
     <simple table>
     | <left paren> <query expression body> <right paren>