we are creating a website for hotel booking. we need to store a large number of images. we think it would be a better option to store images in the filesystem and store the path in the database. But do we have to manually save them? We are using web services from another website to get the images. is there a way to save the images dynamically in the filesystem??
You can use PHP's file get contents function or CURL to download all the images you want to the disk or simply refering the foreign image to your clients and you won't need to store them locally on the server.
If you like Python check the Mecanize lib and BeautifulSoup to parse XML if you need.
Storing in disk vs storing in database has it's beneficts. If you need to scale, it's easier and you can always have a lighttpd or a nginx http servers dedicated to images or simply put it out on other server to balance bandwidth.
It depends on the database, and how you are serving up the images. In general it is better to save the images to disk, depending on how you are delivering them to the client.
Getting the images is usually a matter of some process on the server downloading them from websites and saving them. On many systems you could use wget or curl to download the images and save them.
It also depends on how you are getting the data. If it is some inline binary via XML or something, then you will need to extract that using the features of your application language, and save it to disk.
The mechanics of how to do that vary wildly depending on the implementation language and the hosting operating system.
I think that you should store both remote (web service) and local (filesystem) location in the database, with initial file system location blank. If a user requests an image for the first time, download it, update the file field and show it. With this concept you will only have images your clients need.
Related
As the title says, i am concerned about when i should upload a file on a database rather than the server.
In these days i first encountered the necessity of uploading .pdf files into my web application in order to make it accessible for everyone who needs it.
But my first approach at it was uploading a file into a database.
But that wasn't my case; i just needed to upload a file and, with a download link, make it downloadable from the user.
But on the other side, i wondered, since the big limitations of "blob" type: when should i upload a file into a database rather then the server?
I have always preferred to store items on the filesystem and store the paths in the database.
I think the only advantage to putting it in a BLOB is that you can move the database around and not have to worry about distributing files. For normal websites this wouldn't really matter but for some kind of product like a CMS or website addon it would be a handy way to include a resource file with the distribution...
The reason I prefer the filesystem is because that is what the filesystem is designed for - serving files. I don't see any valid reason to put all that stress into a bottleneck by pushing all the data through the database.
On the other hand the only time I reccomend storing files as a BLOB in SQL is when the images or files contain sensitive data (i.e. Medical Images, etc.) where you need the security that SQL Server provides. Otherwise storing and reading the file from a filesystem is much faster; you can keep a reference to the file's location in SQL Server for the best method.
this question is confusing me so i thought i should listen to an expert voice !.
is it better to upload images to a folder and just save link to mysql, or better upload img itself into a blob mysql field ?
thank you very much
I have often built systems to store images in the database, there are pros and cons to doing this.
Pros:
All your data is kept in one place, if you migrate your website/database the images will just be there
Its easier to sort/delete/etc...
Since you have to serve it via a PHP script, you can perform additional things such as security if required, or image processing (obviously you can do this with flat file too, but you have to make sure the security cant be bypassed by leaving the images in a public directory).
Cons:
Its slower then serving a flat file from the webserver as a PHP script needs to retrieve it, and MySQL needs to return the data.
Your database will become large very fast and not all web hosts take too kindly to this.
The file system is faster for flat file storage and retrieval as thats exactly what a file system is designed for.
Bad. Your webserver does a much better job managing expiry headers and directly loading files from the filesystem. Throughput will be much higher using the filesystem. It's what it's designed for, utilize it.
SQL databases are designed for relational data, not images. You're just loading your database unnecessarily. Store the path/image name instead.
If your application is large i.e you have to display a large number/size of images repeatedly then you should go for first method (storing only image path in database and actual images on file system). This will reduce the processing time to display images moreover consumes less resources. Secondly, if your application requires less number of images then you can store them directly in database . This way it becomes easy to take backups and port application to another OS.
Is it better to read and list images directly from file system using simple php, or is it better to store image meta info and filename in the database and access the images by doing a mysql select. What are the pros and cons of both solutions.
Listing files on a file system is probably the easiest way to accomplish what you trying to do but it's going to be very slow if you are trying to cycle through several thousand directories/files on a networked file system (NFS, CIFS, GlusterFS, etc).
Storing files in a database will create a much more overhead since you are now involving an external application to store information. You have to remember that every time you are using a database you are also using network I/O, authentication mechanism, query parser, etc. At the same time all of this overhead might provide for a faster response then using a networked file system.
To conclude - everything depends on amount of files you are working with and underlying infrastructure. Two major things to look out for are going to be disk I/O and network I/O.
I would do the following:
Upload all the images in one directory
Store references to those images that are tied to the uploader's User ID
Then just select the image URLs that are tied to that ID, and output them however necessary.
People find it easier to store their files within folders and parse that folder with php. If you go the database method the database eventually gets larger and larger and larger.
I can see it becoming personal preference, but I personally have gone with parsing folders for images rather than storing it within a database.
Depends on the scale of what you are doing.
This is what I would be doing.
Store the file metadata in the database. You can store quite a bit of information about this image this way.
Store the image file on a distributed storage system like Amazon S3. Store the path in your metadata. Replication is part of the system. And it easily integrates with Cloudfront CDN.
Distribute the the images through Amazon Cloudfront CDN.
My website allows users to upload photographs which I store on Amazon's S3. I store the original upload as well as an optimized image and a thumbnail. I want to allow users to be able to export all of their original versions when their subscription expires. So I am thinking the following problems arise
Could be a large volume of data (possibly around 10GB)
How to manage the download process - eg make sure if it gets interrupted where to start from again, how to verify successful download of files
Should this be done with individual files or try and zip the files and download as one file or a series of smaller zipped files.
Are there any tools out there that I can use for this? I have seen Fzip which is an Actionscript library for handling zip files. I have an EC2 instance running that handles file uploads so could use this for downloads also - eg copy files to EC2 from S3, Zip them then download them to user via Flash downloader, use Fzip to uncompress the zip folder to user's hard drive.
Has anyone come across a similar service / solution?
all input appreciated
thanks
I have not dealt with this problem directly but my initial thoughts are:
Flash or possibly jQuery could be leveraged for a homegrown solution, having the client send back information on what it has received and storing that information in a database log. You might also consider using Bit Torrent as a mediator, your users could download a free torrent client and you could investigate a server-side torrent service (maybe RivetTracker or PHPBTTracker). I'm not sure how detailed these get, but at the very least, since you are assured you are dealing with a single user, if they become a seeder you can wipe the old file and begin on the next.
Break larger than 2GB files into 2GB chunks to accommodate users with FAT32 drives that can't handle > ~4GB files. Break down to 1GB if space on the server is limited, keeping a benchmark on what's been zipped from S3 via a database record
Fzip is cool but I think it's more for client side archiving. PHP has ZIP and RAR libraries (http://php.net/manual/en/book.zip.php) you can use to round up files server-side. I think any solution you find will require you to manage security on your own by keeping records in a database of who's got what and download keys. Not doing so may lead to people leeching your resources as a file delivery system.
Good luck!
A while a go I had to developed a music site that allowed audio files to be uploaded to a site and then converted in to various formats using ffmpeg, people would then download the uploaded audio files after purchasing them and a tmp file would be created and placed at the download location and was only valid for each download instance and the tmp file would then get deleted.
Now I am revisiting the project, I have to add pictures and video as upload content also.
I want to find the best method for storing the files,
option 1 : storing the files in a folder and reference them in the database
option 2 : storing the actual file in the database(mysql) as blob.
I am toying around with this idea to consider the security implications of each method, and other issues I might have not calculated for.
See this earlier StackOverflow question Storing images in a database, Yea or nay?.
I know you mentioned images and video, however this question has relevance to all large binary content media files.
The consensus seems to be that storing file paths to the images on the filesystem, rather then the actual images is the way to go.
I would recommend storing as files and storing their locations in the database.
Storage the files in a database requires more resources and makes backing up/restoring databases slower.
Do you really want to have to transfer lots of videos every time you do a database dump?
File systems work very well for dishing out files, and you can back them up/sync them very easily.
I would go for the database option. I've used it on a number of projects, some very larger 100+GB. The storage implementation is key, design it poorly and your performance will be punished. See this example for some good implementation ideas:
Database storage allows more scalability and security.
I would go for storing files directly on the disk, and database holding only their ID/url.
This way accessing those files (that can be large, binary files) doesnt require any php/database operation, and it's done by the webserver directly.
Also it will be easier to move those files to another server if you'd want to.
Actually only one upside I can see atm of storing them in database is easier backup - you wanna backup your DB anyway, this way you'll have all data in one place and you can be sure that each backup is full (i.e. you don't have files on disk that aren't used by database entries; and you don't have image IDs in your database that point to nowhere)
I asked a similar question using Oracle as the backend for a Windows Forms application.
The answer really boils down to your requirements for backing up and restoring the files. If that requirement is important then use the database as it'll be easier (as you're backing up the database anyway, right? :o)