List:General Discussion« Previous MessageNext Message »
From:Barry Leslie Date:February 17 2010 4:00pm
Subject:Re: how things get messed up
View as plain text  
Hi,

The problem of BLOB storage with MySQL is not the actual storage of the BLOB
data, it is the getting BLOBs to and from the client. Traditionally MySQL
treats the BLOB data as any other data and as a result there can be major
memory usage and performance issues as the BLOB is passed back to  the
client app. This is why no matter how clever the storage engine is in how it
stores the BLOB, the main problem remains.

That is why the BLOB streaming daemon was developed because it allows the
actual BLOB data to be streamed to and from the database server outside of
the normal MySQL client/server connection.

So you can have the best of both worlds:

- Similar to storing the BLOB in the file system: BLOB references are stored
with the normal table data, not the actual BLOB data, so the tables do not
get bloated, and because the BLOB data is accessed through the BLOB
streaming daemon it has little impact on server performance and memory
requirements are not dependent on BLOB size.

- Similar to traditional storage of BLOBs in tables: the BLOB will
automatically be delete when the row referencing it is deleted and the
application designer doesn't need to implement their own file system based
BLOB storage.

So if you are looking at BLOB storage systems please have a look at

 http://www.blobstreaming.org

or the launch pad project:

 https://launchpad.net/pbms (not pbxt as Paul mentioned.)

Sorry if this is a bit of a plug for PBMS but the subject was BLOB storage
and that is PBMS's sole purpose in life.

Barry


On 2/16/10 8:21 AM, "Martin Gainty" <mgainty@stripped> wrote:

> 
> i agree with jerry
> 
>  
> 
> put date/timestamps on each record..(that way you know when the record was
> created/modified)
> 
> Martin Gainty 
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de
> confidentialité
> 
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
> sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
> oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich
> dem Austausch von Informationen und entfaltet keine rechtliche
> Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
> wir keine Haftung fuer den Inhalt uebernehmen.
> 
> Ce message est confidentiel et peut être privilégié. Si vous
> n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez
> l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de
> ceci est
> interdite. Ce message sert à l'information seulement et n'aura pas n'importe
> quel effet légalement obligatoire. Étant donné que les email
> peuvent
> facilement être sujets à la manipulation, nous ne pouvons accepter
> aucune
> responsabilité pour le contenu fourni.
> 
> 
> 
>  
> 
>> From: jschwartz@stripped
>> To: vikkiatbipl@stripped; vegivamp@stripped
>> CC: mysql@stripped
>> Subject: RE: how things get messed up
>> Date: Tue, 16 Feb 2010 11:02:22 -0500
>> 
>>> -----Original Message-----
>>> From: Vikram A [mailto:vikkiatbipl@stripped]
>>> Sent: Friday, February 12, 2010 4:13 AM
>>> To: Johan De Meersman
>>> Cc: MY SQL Mailing list
>>> Subject: Re: how things get messed up
>>> 
>>> Sir,
>>> 
>>> Thanks for your suggestion,
>>> I will go for blob storage, because our application will maintain the data
>>> on
>>> yearly basis[stupersonal2008, stupersonal2009 etc.]. So i feel we may not
>>> face
>>> such kind of performance issue in our application.
>>> 
>> [JS] It sounds like you are planning to have one table per year. Regardless
>> of 
>> where you put your blobs, I think that is a bad idea from a design
>> standpoint. 
>> It will make it harder to find historical information.
>> 
>> If your database is relatively small, then I'd just keep everything in one
>> table. If it is big, then roll data that is five years old into an archive
>> table. That will give you only two places, and an easy-to-follow rule to tell
>> you where to look.
>> 
>> Regards,
>> 
>> Jerry Schwartz
>> The Infoshop by Global Information Incorporated
>> 195 Farmington Ave.
>> Farmington, CT 06032
>> 
>> 860.674.8796 / FAX: 860.674.8341
>> 
>> www.the-infoshop.com
>> 
>> 
>> 
>> 
>> 
>> -- 
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe: http://lists.mysql.com/mysql?unsub=1
>> 
>  
> _________________________________________________________________
> Hotmail: Powerful Free email with security by Microsoft.
> http://clk.atdmt.com/GBL/go/201469230/direct/01/

-------------------------------------------------------------------------
Barry Leslie

SNAP Innovation Softwareentwicklung GmbH
Senior Software Engineer

Tel: (001) 250 595 4228
Fax: (001) 250 595 4233
Email: Barry.Leslie@stripped
Web: www.PrimeBase.com

SNAP Innovation Softwareentwicklung GmbH, D-22765 Hamburg,
Max-Brauer-Allee 50, Germany
Amtsgericht Hamburg HRB 61066, Geschäftsführer: Ulrich Zimmer, Paul
McCullagh
-------------------------------------------------------------------------



Thread
how things get messed upJohn G. Heim10 Feb
  • Re: how things get messed upBuford Tannen10 Feb
  • RE: how things get messed upIlya Kazakevich10 Feb
    • Re: how things get messed upCui Shijun11 Feb
      • RE: how things get messed upJerry Schwartz11 Feb
        • Re: how things get messed upJohan De Meersman12 Feb
    • Re: how things get messed upJoerg Bruehe11 Feb
    • Re: how things get messed upJochem van Dieten11 Feb
  • Re: how things get messed upMartijn Tonies11 Feb
    • Re: how things get messed upDavid Giragosian11 Feb
  • RE: how things get messed upJerry Schwartz11 Feb
  • Re: how things get messed upMartijn Tonies11 Feb
    • RE: how things get messed upJerry Schwartz11 Feb
    • Re: how things get messed upAnn W. Harrison12 Feb
  • Re: how things get messed upMartijn Tonies12 Feb
    • Re: how things get messed upJohan De Meersman12 Feb
  • Re: how things get messed upMartijn Tonies12 Feb
    • Re: how things get messed upJohan De Meersman12 Feb
      • Re: how things get messed upVikram A12 Feb
        • Re: how things get messed upJohan De Meersman12 Feb
          • Re: how things get messed upVikram A12 Feb
            • RE: how things get messed upJerry Schwartz16 Feb
              • RE: how things get messed upMartin Gainty16 Feb
                • Re: how things get messed upBarry Leslie17 Feb
              • Re: how things get messed upVikram A18 Feb
                • RE: how things get messed upJerry Schwartz18 Feb
                  • Re: how things get messed upJohan De Meersman18 Feb
  • Re: how things get messed upMartijn Tonies15 Feb
  • Re: how things get messed upMartijn Tonies15 Feb
    • Re: how things get messed upJohan De Meersman16 Feb
      • Re: how things get messed upPaul McCullagh17 Feb
  • Re: how things get messed upMartijn Tonies15 Feb
    • Re: how things get messed upAnn W. Harrison15 Feb
      • Re: how things get messed upJohan De Meersman16 Feb
      • RE: how things get messed upJerry Schwartz16 Feb
  • Re: how things get messed upMartijn Tonies18 Feb
RE: how things get messed upJerry Schwartz22 Feb
  • Re: how things get messed upVikram A24 Feb