Ok, maybe I'm missing something here but I'm looking at various PHP hosting options and I see things like "10 MySQL databases", or 25 or even unlimited.
Now I've worked on sites with an Oracle backend that have 10,000+ concurrent users and we've had... one database.
The idea of a database is, of course, that you can store whatever you want in it. So why is it for MySQL that the number matters? Is there some table, row or overall database limit I'm not aware of (entirely possible)? Or is it a question or concurrent connections? Or some other performance issue (eg sharding)? The sharding aspect seems unlikely because even basic hosting options (ie under $5/month) I see with 10 databases.
If someone could clue me in on this one, it'd be great.
It's mostly a marketing tactic, although there are some technical and historical considerations.
First, apologies if this is obvious, but SCHEMAs are to Oracle as DATABASES are to MySQL (in over simplified terms, a logical collections of tables).
The host is saying you can have XX number of configured logical databases on a server. Lots of web applications need a database to run. Modern web applications like Wordpress, Movable Type, Joomla, etc., will let you name your tables with a custom prefix. However, if an application doesn't have this configuration feature that means you need one database per install. Also, in a similar vein, if two applications have the same table name, they can't coexist in a single database. Lots of early web applications started out like this, so early on number of databases was an important feature to consider.
There's also access and security. While MySQL (and other databases) can be configured to give users fine grained access-control down to the table and column level, it's often easier to create one user who has full permission on a logical Database. This is important to people who sell services but pass off the actual hosting of completed sites/applications to the shared web-host.
Some people like one database per app
It's marketing, not technical. They want something to advertise. "10" sounds like a good number.
For development purposes, sometimes it's good to make a copy of your entire database to test new software against. Beats renaming all the tables in your code (although apps like Wordpress let you specify a prefix for all your table names in case you don't have the luxury of multiple DBs).
When I used shared hosting, I set up a separate database for each site/client for custom apps, and if you use Fantastico to install applications it will use a database for each one by default.
I believe the limits are there to prompt you to upgrade to the next tier of service when you outgrow the current level.
Nick is partially correct, but it also has to do with people who will try to host multiple sites on one shared account and will use a different database for each and a script to serve the correct content with a little dns masquerading.
Additionally its possibly a marketing perspective.
If you're only setting up databases for yourself, the low count is fine. but for commerical users, whom may want to have multiple sites for multiple clients on the one service, trying to cut corners, you're likely to need 1 Database ( or more ) per client/project.
So putting a limit on number of databases controls somewhat the variety services you offer, and potentially limits potential for your "resale" value, ie: to stop you buying 1 plan and then selling it on to somebody else, like "subleasing".
This is mainly for when you are hosting multiple sites on the same box. For me, I buy/sell a lot websites so I need to be able to keep each website as detached from the others as possible.
Related
I have an application which is going to be distributed to a hosting platform, most probably phpfog.
It is very similar to how WordPress.com operates, where each customer can host their own individual installation of the app on our servers. We host the 'work' files and provide the database (However, it is NOT WordPress; it's a custom app).
Each user of the application has their own separate MySQL database.
I am wondering what the most cost-effective service would be to provide this. It seems that most cloud services offer, for instance, one massive 50GB database. It is definitely conceivable that instead of an individual database, we have one huge one and prefix all the tables per user. But that seems really bloated and unwieldy. It's also not really possible without major structural changes to have one big database for everyone (And the same tables inside it for everyone) as the app is primarily designed to be standalone.
Each database really won't get that big. We are talking low GB - I'd suggest the biggest would be 5GB. However, there will be a LOT of them as obviously it's one per customer.
What would be the most cost- and performance-effective way of handling this?
Amazon RDS in fact provides a database server rather than an individual sales page; I misunderstood their offerings.
In this case, RDS is a drop-in replacement for existing MySQL databases and will work perfectly.
I have used sql (mostly mysql) for years but not to a professional standard, so I'm looking for a shove in the right direction.
I am currently designing a web app that will collect user's names/addresses/emails etc in one set of tables, as well as other personal information in another set of tables. These would most naturally reside in one database, but I've been considering splitting the user contact information in one database on a separate server and all the other information into another database/server, the theory being that a hacker would have to break both systems to get anything very useful.
I've done searches off and on for a few weeks and haven't found this type of design discussed much so far. Is this generally done? Is it overkill? Is there a design method to approach it, or will I have to roll it all on my own?
I did find Is splitting databases a legitimate security measure? which I guess is saying that this approach is likely overkill.
I tend to think this is overkill.
Please check my answer on this question: Sharing users between 2 databases
Keep in mind to address separately database design and data access
security issues. Data access security should not lead you to illogical
choices in database design.
IMHO that seems to be wrong. By splitting data across 2 DB you will only increase complexity without reasonable security profits.
I think this is where data encryption can be used. Generate encryption key based on user credentials and encrypt/decrypt sensible data by user requests. Since private data must be shown only to that user, everything should be ok.
Here's an approach I used before:
Server1: DB
Server2: SC
DB is in a network domain that is accessible by the public, but cannot access SC
SC is in a network domain that is not accessible by the public, but can access SC
DB is where you stored all pertinent information, including the 'really important stuff'.
At a specified interval (I used 5 seconds) SC checks DB for any new records in any table it may want to monitor (there is a job or scheduled task) and encrypts the important information.
Although I was utilizing SQL Server 2005 and was able to work in two domains (a private(intern al) and public(for client access) and that what I just shared was a stripped down (removed as much MSSQL-exclusive parts), simplified version, with some effort I think it would be possible to recreate something similar in mysql, especially if you can host your two databases in separate, physical machines.
While many will also think this is overkill, this idea had been implemented. It costs more, and requires more work when it's data reporting time but the clients were pleased.
I'm planning on building two applications using Zend Framework that are very similar but serve two different purposes that can't be part of the same application or be combined into one. However, modules are something I'm considering.
The issue I'm running into is if a user registers for the first application I want that information be available to the second application, hence sharing a user table or user database. Because the applications are so similar that they have the same database tables with some having different fields, I'm not sure if I should have three, two or one databases. Three databases would be User Database, App1 Database, App2 Database. Two databases would be User Database and App1+2 Database with prefixed tables. One database would be User and App1+2 Database.
I'm trying to give as much information as possible, but because this is for a client I can't really discuss the details in depth. Also, this is something the client wants and other than not being able to figure out how to set it up, I'm not sure this is best.
My Questions
Of the options above, which would
serve best, or other?
Should I have a shared user dataset across two applications or should the users have to register again?
No matter of the choice you think is best, how would/should I implement it into Zend? Just a brief is needed no need for code.
I hope this is enough information to give me the best answer, but if more information is need, please let me know.
Thanks!
Why have multiple databases? Use just one database and prefix the tables that differ for the two applications. For example:
users
app1_otherdata
app2_otherdata
This way users' data will be easily accessible to both apps and you could still have a relatively independent database structures.
Question 2 is something you really should discuss with your client.
Once you know your clients' preference you could eg. suggest using a single sign-on approach for the sites, but I would certainly keep both DBs apart. So either your 2 DB (with separate user DB per app) or your 3 DB solution (with separate user DB/single sign-on) makes more sense to me.
I am developing a website. There is an English version, Japanese version and Chinese version. Different version is for different language speakers. If you are a registered user of the English version, and you want to use the Japanese version, you still need to register on the Japanese version. So should I create one database and put all tables into this database or should I create 3 databases, each database for each version?
If these sites share no data I would say it's better to create a separate database for each. This will prevent you from accidentally damaging other version's tables if you mess up any queries.
make the tables reasonably separate, but don't close the door to possible future requirements. databases in mysql are a fine mechanism that fits both: it's a nice way to namespace the tables, and the separation is weak so you won't have problems with cross-database queries. use schemas in more sophisticated database systems.
It depends as RaYell tells on the amount of data/tables shared among these different versions. I would recommend that you look into schema support for your particular database, and partition according to schema for data separation, and by different users owning the separate schema's for security access.
In Oracle database, for example, each user is assigned it's own schema, so you could have user_en, user_jp.
Alternatively you could look into multilingual database design.
It really depends on how much data is to be shared (or combined for reporting). Even if management say "no, everything is separate" now, that'll change in 5 minutes. Always. :-)
I've worked on a number of multi-tenant systems, and would recommend a single database, designed so each site has its own ID; the negative side is the SiteID column must then be included in most of the tables, foreign keys and the associated queries. On the positive side it does allow a site's data to be extracted easily if one site is sold off, or its server is moved to a separate location for legal reasons, etc.
I'd also recommend using Unicode (or UTF-8) for all user-visible or possibly-localizable data. It'll save a lot of grief later on.
Definitely it is better to have separate databases, otherwise you will have to come up with different naming conventions for tables etc. If you have code that accesses these tables, then you will need to modify all that code as well instead of just reconfiguring the database bindings.
The answer, as usual, is "it depends." The real question, I think, is how you plan on maintaining your system.
If you are going to have a single website that allows the user to select language (or have different versions appear at different URLs), then I would use a single database, a single set of application scripts, etc. This way minor changes in schema only need to be reflected in one database. Each table with user content would have some kind of column with a SiteID column, much as devstuff recommends. A second advantage to this approach is that you can have a single user authentication system and actually let users switch from one system to another --- or eventually fuse them all together.
If you are going to have multiple applications, multiple programmers, multiple skins, etc., you may find it easier to have multiple databases. But this means that you will also have dramatically higher development costs. In some cases this is worth the trouble; in most cases it is not.
I need to set up a MySQL environment that will support adding many unique databases over time (thousands, actually).
I assume that at some point I will need to start adding MySQL servers, and would like my environment to be prepared for the case beforehand, to make the transition to a 2nd, 3rd, 100th server easy.
And just to make it interesting, It would be very convenient if the solution was modeled so the application that queries the databases sends all the queries to a single address and receives a result. It should be unaware of the number and location of the servers. The database name is unique and can be used to figure out which server holds the database.
I've done some research, and MySQL Proxy pops out as the main candidate, but I haven't been able to find anything specific about making it perform as described above.
Anyone?
Great question. I know of several companies that have done this (Facebook jumps out as the biggest). None are happy, but alternatives kind of suck, too.
More things for you to consider -- what happens when some of these databases or servers fail? What happens when you need to do a cross-database query (and you will, even if you don't think so right now).
Here's the FriendFeed solution: http://bret.appspot.com/entry/how-friendfeed-uses-mysql
It's a bit "back-asswards" since they are basically using MySQL as a glorified key-value store. I am not sure why they don't just cut out the middleman and use something like BerkeleyDB for storing their objects. Connection management, maybe? Seems like the MySQL overhead would be too high a price to pay for something that could be added pretty easily (famous last words).
What you are really looking for (I think) is a distributed share-nothing database. Several have been built on top of open-source technologies like MySQL and PostgreSQL, but none are available for free. If you are in the buying mood, check out these companies: Greenplum, AsterData, Netezza, Vertica.
There is also a large number of various distributed key-value storage solutions out there. For lack of a better reference, here's a starting point: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/ .
Your problem sounds similar to one we faced - that you are acting as a white-label, and that each client needs to have their own separate database. Assuming this concept parallels yours, what we did was leverage a "master" database that stored the hostname and database name for the client (which could be cached in the application tier). The server the client was accessing could then dynamically shift its datasource to the required database. This allowed us to scale up to thousands of client databases, scattered across servers.