RE: GD to database directly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[snip]
Kevin, you have more than once pointed out using a RAW format for
operating the data system, what exactly do you mean? The database
becomes the OS? If so, how do you set that up? It is something that I am
not totally familiar with. 
[/snip]

I did some research and went back to Kevin's original statement;

[kevin]
databases can be stored on RAW partitions, thus eliminating FILE SYSTEM
overhead
[/kevin]

Here is what I found;

[quote]
raw partition vs filesystem store? 

> What are pros/cons as far as performance, reliability, and ease of 
> backup/restore? 
> 
> Anyone have any experience running Innodb on raw partition? 

raw partitions are beneficial only in some old OS/hardware
configurations 
where fsync is extremely slow. In most computers, you only get a < 5 % 
performance improvement from raw partitions. 

> Any thoughts as to best filesystem for Innodb? What about pros/cons of

> journaled filesystems when in use with Innodb (i.e. transactions)? 

All major Linux file systems seem to have almost the same performance. 
[/quote - Heikki Tuuri]

Use of MySQL on a RAW partition I limited to InnoDB type; (note the use
of 'may' in the quote)

[quote]
http://dev.mysql.com/doc/refman/5.0/en/innodb-raw-devices.html

"You can use raw disk partitions as data files in the shared tablespace.
By using a raw disk, you can perform non-buffered I/O on Windows and on
some Unix systems without filesystem overhead, which may improve
performance."
[/quote]

[quote]
A raw device can be bound to an existing block device (e.g. a disk) and
be used to perform "raw" IO with that existing block device. Such "raw"
IO bypasses the caching that is normally associated with block devices.
Hence a raw device offers a more "direct" route to the physical device
and allows an application more control over the timing of IO to that
physical device. This makes raw devices suitable for complex
applications like Database Management Systems that typically do their
own caching. 
[/quote - SCSI HOWTO]

Based on what I read utilizing a RAW would probably require most PHP'ers
to reconfigure their systems in major ways, including the database type,
disk partitions, etc. I don't know about you, but most would consider
Heikki Tuuri an expert on MySQL systems and Tuuri's thoughts indicate
that RAW partitions vs. file systems are a wash unless you have fsync
problems. It would appear that the only benefit comes from not having
the file system doing the caching.

[previous statement]
There are a lot of us using MySQL (and PostGreSQL) along with PHP and in
practice we have found that storing images in the database to be less
than ideal from both a performance and backup POV. The reasons range
from speed to overhead to ease of use. On our hardware. It not only has
to do with storing and retrieving BLOB data, but also things like
indexing, OS qwirks and the like.
[/previous statement]

I still stand by this, and amend by saying that using a RAW partition
for database storage is typically beyond the needs of most PHP'ers as it
gains nothing in performance and requires that much additional
maintenance be performed on the database as well as the OS for
maintenance of the RAW partition.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux