[bind10-dev] MySQL vs PosgreSQL data source flamewar - FIGHT!

[JINMEI Tatuya / 神明達哉]

At Fri, 11 Jan 2013 20:22:15 +0100,
Shane Kerr <shane at isc.org> wrote:

> > - revisiting the representation of names (currently it only works with
> >   trivial alpha-numeric characters).
> 
> Yes, that makes sense. IIRC we've discussed this on-list before
> (although I can't seem to find the mail right now).
> 
> My recommendation was that we should include a column that has the
> names converted to hex values of the ASCII:
> 
> "isc.org"    -> 697363..6f7267
> "f0o.c\000m" -> 66306f..63006d
> 
> This will preserve sort order at the costs of using 2x as much space
> and not being human readable (we may also include a human-readable
> column too).

Specific format would be out of scope of this thread, but one quick
point: we should also make sure comparison is "case insensitive".  So
(e.g.) we'll need some kind of normalization, too.

> > - or maybe using binary blob for some
> 
> Like... signatures?

For RDATA in general.  Building an Rdata object from text is generally
expensive (perhaps marginal, though, comparing to the DB query
overhead).  Maybe also names (we need "reversed" names with some trick
like the above to give them ordering, but we don't need to do it for
original names).

> This all seems to argue a bit for a refactoring into something like:
> 
> +-------------+
> | data source |
> +-------------+
>     ^      ^
>     |      |
> +-------+ +-------+
> | inmem | |  SQL  |
> +-------+ +-------+
>            ^  ^  ^
>            |  |  |
>    +--------+ | +------------+
>    | SQLite | | | PostgreSQL |
>    +--------+ | +------------+
>            +-------+
>            | MySQL |
>            +-------+
> 
> Then we can include all of the above optimizations for each SQL
> back-end, right?

I don't understand this architecture.  Could you be more specific,
maybe with some example?

> > And, at a higher level, it's better to have more confidence about
> > common use cases with the DB backend.  I've repeatedly requested that
> > information, but apparently we are failing in it (except for one
> > pointer you previously provided).  If it was because we were not so
> > serious about it, it's the time to be so.  If it's really because such
> > information isn't available, maybe we need to try whatever we come up
> > with and see if it's accepted by real users.
> 
> We have at least 2 users who are having problems with SQLite today, so
> we know we need a "real" SQL back-end. Their current us case is "serve
> my zone without pain", AIUI. :)

They use SQLite simply (or mainly) because that's the only available
tool even if they only need in-memory backend.  In that sense it's not
that useful information in this context.  For example, I believe JPRS
wouldn't bother to play with SQLite3 if BIND 10 provides BIND 9-like
plain text (or non DB-based in general) data format.  What I wanted to
see is use cases of someone who specially wants database-based data
sources for some specific reasons.

> We know we have to revisit the name storage, as it can break zones from
> the real world.
> 
> Everything else is probably not necessary, but I doubt you would ever
> find a user who would say "no" to additional performance.

If it's "additional", yes, but we don't even know if the current
performance (and/or that of a straightforward port of the current
backend for other DBs) is "sufficient".  If it's not, performance
enhancement is not a bonus, but a critical requirement.

> Perhaps you can explain what you expect to get out of common use cases?

It's mainly for performance, in various sense: query-response
throughput, update throughput, read-write concurrency, and other
scalability related issues (how we can allow users to manage millions
of zones, etc).

It's also related to feature: whether DNSSEC should be integrated (or
even necessary) or whether it's okay to be able to load singed data to
DB, for example.

> What kind of changes would you expect from the requirements or
> implementation?

Whether/how we cache previous lookup results; overall query handling
logic (it would be quite different for leaf and delegation-centric
zones; different whether it has wildcard; or whether it's DNSSEC
signed).

---
JINMEI, Tatuya