Hi!
I'm about to blow up^W^Wrefactor the afsql destination to increase both
performance and functionality. To do this properly, and to satisfy most
needs, I'd like to ask the greater community (especially those of you
who have more experience with logging to SQL than I do!) about the
plans laid out on the paragraphs below.
Those of you who do log into SQL one way or the other, but aren't
interested in technical mumbo-jumbo, please skip to the end of this
e-mail, I'd have a few questions, for which all responses would be most
appreciated!
Where, when, how??
==================
There are multiple goals to accomplish, which I believe are not
exclusive: we want to keep the sql() statement in the configuration
file, and maintain backwards compatibility aswell. On the other hand, we
want to improve performance too, and that is best accomplished by using
the native database libraries. To this end, I propose we introduce new
database types: "mysql-native", "postgresql-native", "sqlite-native",
and so on and so forth.
The first step will be to rearrange the current afsql driver, so that it
has a generic configuration interface, but can have multiple backends
(dbi - the only existing backend right now; and one for each native db
client). I'd change the AFSqlDestDriver structure to only contain the
configurable data and nothing else. The backends would subclass this
type (much like how AFSqlDestDriver subclasses LogDriver) and add their
own.
The reason I want to do this, making the AFSqlDestDriver a config-only
interface instead of keeping larger chunks of code there (for example,
the threading code) is because I do not want to limit my possibilities:
I can imagine an SQL driver utilizing multiple writer threads
easily. However, neither model works for all databases (concurrent
writes to SQLite are usually not a good idea, for example).
And that's about the generic interface! Lets dive into the more
interesting parts: the native drivers. Since MySQL is the most used
server out there, that will be the first I tackle.
My goal with that is to implement a driver that is not only faster than
our current destinations, but one that is also faster than the perl
scripts people have been using until now, when they wanted top
performance. All that while maintaining reasonable flexibility.
An ambitious plan, but hopefully not impossible.
I've been reading the MySQL documentation for the past few hours to
explore my options, and found a few ways to increase our insert speed:
mysql_list_tables()
-------------------
Instead of doing a full select to verify that a table exists, we can
just try to list the table. This is probably not a significant increase,
but every bit counts.
Prepared statements
-------------------
We'll use prepared statements wherever possible - I expect this alone
will result in a measurable performance increase, since the server will
not have to parse each and every insert - only once, we'll bind
variables thereafter.
LOCK TABLES / transactions
--------------------------
Currently, syslog-ng can do bulk-inserts, wrapped in a transaction. But
that only works if the MySQL table we insert to is on a storage engine
that supports transactions (InnoDB). However, MyISAM has been the
default for quite a while, and that does not support transactions to the
best of my knowledge.
In this case, insert performance can be increased by locking the tables
for a few hundred inserts at a time, and unlocking after: poor man's
transactions, to some extent.
This, however, is more of a workaround than a real improvement.
Insertion plans
===============
There's a couple of alternative ways to improve insert speed by changing
how we actually do them. All have their pros and cons, which I will try
to enumerate below.
LOAD DATA INFILE
----------------
The fastest way by far is LOAD DATA INFILE, which is what people use in
the various perl scripts, as far as I remember. The downside is that -
as far as I saw so far - this does need a temporary file, which has its
downsides, like writing to disk (unless put on tmpfs or similar). An
option which I haven't tried would be to use a pipe(), so that the data
never hits the disk.
But nevertheless, the mysql-native db type will have an option to use
LOAD DATA INFILE.
* Pros:
+ The fastest way to insert
* Cons:
- Needs a temporary file, with all its drawbacks, some of which can
be worked around.
- Serialisation is costlier than simple INSERTs.
- No fine-grained error checking: if something goes wrong, the whole
LOAD will have to be dropped (unless we add code that splits bulks up
into smaller chunks, and retries - but that's something I want to
avoid if possible)
For LOAD DATA to work, we will have to format the data to insert into a
suitable format, and if there's an error in the serialisation somewhere,
we'll have a hard time to figure out where the problem is, and syslog-ng
will just give up.
Also, beating our data into a suitable format isn't exactly cheap,
either (think escaping: processing large amounts of string data,
possibly changing strings - there's both processing and memory
ramifications involved).
The need for a file is also a (minor) issue. I suppose named pipes would
work, that way data never hits the disk between syslog-ng and
mysql. However, that still involves copying data around. We'll see if
these affect LOAD DATA's performance badly enough (they probably don't).
INSERT INTO ... VALUES (...), (...), ...
----------------------------------------
This is considerably slower than LOAD DATA, but still faster than using
INSERTs (even if we use transactions / locking for those).
The downside is that - like with LOAD DATA - serialisation is still
costlier than INSERTs.
* Pros:
+ Reasonably fast
+ Does not require neither a temporary file, nor gross hacks
* Cons:
- Slower than LOAD DATA
- Serialisation can be costly.
- No fine-grained error checking
Serialisation is a little less costly than in LOAD DATA's case, but this
can be worked around a little with prepared statements (with a fallback
to parsed ones, in case we have to insert less data than originally
planned).
The same issues with error handling persist, though.
INSERT ... DELAYED
------------------
The DELAYED strategy works best if we have multiple writer threads, as
in this case, INSERT becomes a fire & forget call, and we can return to
our business far sooner. This does not work all that well with bulk
inserts, though.
* Pros:
+ Reasonably fast with multiple writers
+ Simple & fast serialisation
* Cons:
- No error checking at all (except for connection and syntax
errors)
- Probably still slower than LOAD DATA
The advantage of this is that we can get the data from syslog-ng to the
mysql server faster than any of the other methods, and then the work is
off-loaded to the server. This has the potential of being faster than
any of the above, but with the cost of hardly any possibilities to
recover from an error, as we get no feedback after inserting: did it
succeed? did it not? We'll have no idea.
The Plan
========
The plan is to implement all the strategies above, and measure them
against each other and external scripts. This will take a little time,
because I want to get the architecture right, and figure out whether we
want a single or multiple writer threads (per-destination, of course),
or if I want to make that a configurable option aswell.
Once done, and people are happy with it, I'll move on to the next
database (PostgreSQL, to scratch my own itch too).
The Questions
=============
What I'd like to know most, is, that would YOU expect from a native
mysql destination?
Apart from speed, what would you want from it, that the current driver
does not support, but which is possible via external scripts?
If you happened to read through my wall of text above, did I miss
anything important?
Cheers,
--
|8]