[DiscordArchive] eh the video is 20 years old, had you not seen it before?
[DiscordArchive] eh the video is 20 years old, had you not seen it before?
Original source
eh the video is 20 years old, had you not seen it before?
rektbyfaith
06-11-2025, 01:01 PM #1Archived author: Nyeriah • Posted: 2025-06-11T13:01:36.239000+00:00
Original source
eh the video is 20 years old, had you not seen it before?
Original source
it is aimed at u in sense that when u came with "guys mysql is old and slow what about switching to scylla" it reminded me of that video
rektbyfaith
06-11-2025, 01:05 PM #2Archived author: Rymercyble • Posted: 2025-06-11T13:05:16.272000+00:00
Original source
it is aimed at u in sense that when u came with "guys mysql is old and slow what about switching to scylla" it reminded me of that video
Original source
alright it's cool
rektbyfaith
06-11-2025, 01:23 PM #3Archived author: lucian_apetrei • Posted: 2025-06-11T13:23:19.024000+00:00
Original source
alright it's cool
Original source
This whole discussion is ultimately pointless and anyone who spent more than 10 seconds looking at the database structure should be able to understand why. I'm sure scylla among other nosql database have their uses, but this is not one of them.
rektbyfaith
06-11-2025, 01:35 PM #4Archived author: Takenbacon • Posted: 2025-06-11T13:35:36.120000+00:00
Original source
This whole discussion is ultimately pointless and anyone who spent more than 10 seconds looking at the database structure should be able to understand why. I'm sure scylla among other nosql database have their uses, but this is not one of them.
Original source
It seems like your suggestions are coming from a typical web application architecture mindset, which emphasizes statelessness and scalability. In that model, it's normal for each request to trigger multiple reads from the database, and that makes sense when you're dealing with isolated, shortlived user interactions.
However, an MMO backend operates under a very different paradigm. Most MMO servers, including AzerothCore, rely on a tick based game loop architecture. This loop runs continuously and updates the entire game world, including all players, NPCs, and other objects every few milliseconds. To maintain a responsive experience, each iteration must complete within a strict time budget, typically under 50 ms.
Introducing blocking or synchronous database calls inside this loop would be disastrous. Even with a highly optimized database like ScyllaDB, you simply can't meet that performance requirement at scale when you have thousands of concurrent players and game objects. The architecture just doesn’t allow for external latency during world updates.
That's why AC designed to hold all relevant game state in memory during runtime. The database is only used for persistence - loading player at login (asynchronously, outside the game loop), and saving progress periodically (again, outside the loop). During actual gameplay, the server behaves like a read optimized NoSQL cache, backed by hundreds of inmemory hash maps, vectors, and other structures optimized for fast access.
So in our case, switching to a different database like ScyllaDB wouldn't have any noticeable performance impact during runtime, except perhaps in startup time. In fact, we might even lose consistency guarantees, since ScyllaDB doesn’t support full ACID transactions, which are important for our persistence layer.
rektbyfaith
06-11-2025, 08:56 PM #5Archived author: walkline • Posted: 2025-06-11T20:56:27.760000+00:00
Original source
It seems like your suggestions are coming from a typical web application architecture mindset, which emphasizes statelessness and scalability. In that model, it's normal for each request to trigger multiple reads from the database, and that makes sense when you're dealing with isolated, shortlived user interactions.
However, an MMO backend operates under a very different paradigm. Most MMO servers, including AzerothCore, rely on a tick based game loop architecture. This loop runs continuously and updates the entire game world, including all players, NPCs, and other objects every few milliseconds. To maintain a responsive experience, each iteration must complete within a strict time budget, typically under 50 ms.
Introducing blocking or synchronous database calls inside this loop would be disastrous. Even with a highly optimized database like ScyllaDB, you simply can't meet that performance requirement at scale when you have thousands of concurrent players and game objects. The architecture just doesn’t allow for external latency during world updates.
That's why AC designed to hold all relevant game state in memory during runtime. The database is only used for persistence - loading player at login (asynchronously, outside the game loop), and saving progress periodically (again, outside the loop). During actual gameplay, the server behaves like a read optimized NoSQL cache, backed by hundreds of inmemory hash maps, vectors, and other structures optimized for fast access.
So in our case, switching to a different database like ScyllaDB wouldn't have any noticeable performance impact during runtime, except perhaps in startup time. In fact, we might even lose consistency guarantees, since ScyllaDB doesn’t support full ACID transactions, which are important for our persistence layer.
1 Guest(s)
1 Guest(s)