1

We are small start-up now, we don't have a DBA.
if our project succeed, it will have a lot of data that will likely need to be distributed over several machines.
So we want to make that step easier, so what we should take in consideration now to make it so?
What we can think of now is using uuid instead of autoincrement ids, but even that we don't know how much that will affect performance?

So i using uuid is right choice? and what else we should do?

0

You have to determine why the db is being distributed.

Replication: A company may have branch offices each with their own database server that replicates their data to the corporate office which has its own server. Different brands handle this differently and probably recommend guids or the main server uses compound keys like: RegionID & UID.

Fault Tolerance What to do when your database server crashes? How much time can you afford to be down? You'll need another one to switch over if you want to shorten this time. It may be located in a different datacenter. I don't think you design the database all that differently. There are just other software and ways of doing the switching and getting the production box back in service.

I'm guessing you're concerned with outgrowing a single machine for performance reasons. There are many steps you can take before you get there.

  1. Design your app to make changing the database as easy as possible.
  2. Design the database correctly. You may not have the luxury of normalization. Throwing indexes at the problem needs some thought as well.
  3. Query data efficiently. Know you database brand. Utilize tools available (query analyzers). Compare and contrast different methods.
  4. Look for tools to cache the data. I can't remember what they use, but I believe SO sites do this, as well as, basecamp.com. Pretty big sites that as far as I know have managed to use RDBMS, provide lots of info with one big box.
  5. Buy a bigger server or increase the power of an existing one. If the money is there, this could be your first choice, but don' let it be a crutch.

Based on the claims of servers like NUODB.COM, you can just create your app using good old SQL and just keep throwing servers at various failure points (transactions, writing to disk, etc.) on the fly without making any app changes.

If at some point you need more database power, I hope this is a result of generating more revenue. With that, you can hire at least a part time DBA with skills in database tuning.

0

UUID or GUID are used to be globally unique identifier. as discussed in the Postgres Documentation. there are no methods that are totally appropriate to generate it.However, postgres have some useful generators.

The performance effect on your software depends on the overall database size and the average query size.in my own opinion there is very small effect when using the Guid over auto increment id which is negligible.

I wish you the best with your start up, and in order to have a solid software solutions company you need to pay attention for software architecture and design pattern to make highly scalable , easy to maintain software.

Good luck.

  • thanks for your answer. is there anything else i need to do beside using GUID? – Marwan Apr 20 '14 at 0:45
0

If your concern is storage, meaning that you fear that a single (database) machine will not be able to keep all your data, you better design in a way that will enable you to scale out by sharding your data.

Sharding means that each database machine will hold only part of your data, each atomic part is called a 'shard', with database nodes holding one or more shards, each shard has one or more replicas.

The idea behind sharding is that, given that you know on which shard the relevant data is, you query only a server which might have the data. Writing data is also done only in the relevant nodes, which minimizes database locks. Some NoSQL databases support this out of the box (like elastic search).

Not all data can be sharded, since it breaks if you want to query the whole dataset, or if you can't figure out reliably and idempotently on which shard your data should be, but if your data is isolated (for example - you have many users, but each user is interested only in his own data) - it could be done quite easily.

Not the answer you're looking for? Browse other questions tagged or ask your own question.