Tag Info

New answers tagged

1

I'd suggest that you look up a Master-Slave mirroring between your offsite MySQL database and one that you can host locally(its not that hard to host one on your desktop). Why? Instead of asking python to ask your offsite database every now and then if there are new changes, why not have that database update itself in a local database that you own. That ...


1

I would not recommend updating the records of all active auctions every second. I think the better way would be to store an expiration time for every auction as date and time (or a timestamp) and modify it only when an event happens (eg. when someone bids the auction item, set it to current_time+2 minutes). To make everyone see the same value, you should ...


0

I would avoid any ad-hoc, on-demand, database replication. Ideally you want a single consistent, logical user database across all of your nodes, for disaster purposes. @Wardy's recommendation of a service bus is a good one. I won't discuss different cluster architectures, but will address the issue of network bandwidth and transaction volume. With high ...


1

Sounds like a typical use for a service bus based solution. I solved exactly this problem but for keeping running servers live and interconnected and in sync with each other in my MMO server framework. The simple answer is "don't try and sync the data once its in the database use an event and handle it in multiple locations". It's basically like taking ...


0

Have you considered pre-creating a number of databases prior to use and when a new client creates an account, record the mapping from the client account name to the pre-created DB? This way you can limit denial of service attacks that auto-create too many databases for the DBMS to manage (because the list of pre-created databases would run out) and you'd ...


2

Your use case is this (please correct me if this is wrong): Users post updates. Users can have subscribers. Subscribers see the updates, and can filter based on which ones they have not seen before. Your data model then should not contain a notifications table listing the notifications per recipient. The data model would look like this: Users ...


5

Don't insert the 2000 rows when the user posts something. Instead, send a message thru a a message que saying "New post, ID is x". Then have a background process take the message off the que and process it, including generating notifications. Basically, you return a web page to the user ASAP by only doing the essentials and then do all the heavy work on ...


0

You can able to greatly increase the speed by putting your inserts inside a transaction. You can also move your prepare and bind statements outside, if you need so. The idea I generally use when working with transactions looks like this (semi-pseudo-code): try { // First of all, let's begin a transaction $db->beginTransaction(); // A set of ...


2

For a system which can handle >2000 users, adding 2000 records to a table should not be much of a problem, otherwise you have chosen the wrong hardware. If the one or two seconds block your main process for too long, add the records asynchrounously in a separate thread or process. And if you have concerns about getting too many notification records in that ...


3

Sit down and write the client/server properly yourself. If you are not willing to implement all of the protocol, just doing part of it can leave you with significant and strange breakages when some application tries to: prepare a statement iterate over a result set do a transaction (and a rollback!) do something 'at the same time' as another thing (can ...



Top 50 recent answers are included