Subject | Re: Record Encoding |
---|---|
Author | adem |
Post date | 2005-05-15T11:34:51Z |
From: geoff@... (Geoff Worboys)
Already, disk size is assumed to be practically infinity. We are
concerned with I/O speed which SSDs will not drastically alter.
Unless I see something like InfiniBand applied to SSDs, I will
consider SSDs to be hardisks with a different internal media
and faster seek times.
X86, X86_64 CPUs, dual and/or dual-core,
say, upto 16 GB RAM
10BaseT, 100BaseT, 1000BaseT,
ATA133, SATA150, SCSI320
RAIDx (inc. RAID5/RAID50/RAID6)
For immediate tomorrow:
SATA300, SANs
10GbE (10 Gb Ethernet)
ToE (TCP Offloading Engine)
Compression and Encryption Engines
IOW, from what I see, only the storage and network will see
any major improvement. But, I do agree that it is a fool's
game to predict anything into the future.
Cheers,
Adem
>True, but how does this alter the basic assumptions to Firebird?
>BUT a relatively small technological break through could bring
>SSDs back into the limelight quite quickly.
Already, disk size is assumed to be practically infinity. We are
concerned with I/O speed which SSDs will not drastically alter.
Unless I see something like InfiniBand applied to SSDs, I will
consider SSDs to be hardisks with a different internal media
and faster seek times.
>The moral of the story is that development really needs to beAFAIS, for our purposes, here and now is:
>concentrated in the here and now. Sure, we keep an eye on what
>may be coming and try to enable our developments to take
>advantage in such areas, but to base success on what may
>appear is a risky business.
X86, X86_64 CPUs, dual and/or dual-core,
say, upto 16 GB RAM
10BaseT, 100BaseT, 1000BaseT,
ATA133, SATA150, SCSI320
RAIDx (inc. RAID5/RAID50/RAID6)
For immediate tomorrow:
SATA300, SANs
10GbE (10 Gb Ethernet)
ToE (TCP Offloading Engine)
Compression and Encryption Engines
IOW, from what I see, only the storage and network will see
any major improvement. But, I do agree that it is a fool's
game to predict anything into the future.
>I believe that IB/FB has had the right approach so far. LeaveThanks. This is gist of what I have been trying to say :-)
>such things as compression and encryption to external services.
>We already have operating systems services for on-the-fly
>encryption and compression. Similarly there are network
>services to fulfill the same requirements. (Note that
>encryption also provides compression.) The real advantage of
>these external services include:
>
> - they are user configurable; can be turned on/off as per
> the needs of the particular installation, with users
> choosing an implementation that best suits them.
>
> - they work for other things besides FB; so users can
> configure ONE service and have the advantage across
> all their applications.
>
>So why does FB need to repeat what is already available in
>tested, stable and efficient implementations?
Cheers,
Adem