You need some sort of a viewport into the larger area. Then, when the viewable area is changed you will need to draw it based on what should be displayed there (you can obtain this information from a database, for example -- in particular, PostgreSQL has some specialized indexing features available that are optimized for the needed types of queries).
PostgreSQL (free and open source)
You'll also want to make sure the areas that are no longer needed will not remain in memory for too long, otherwise a player who likes to explore with the "run 20 times faster" boots will fill up their computer's memory quickly.
One problem you might experience will be that as you load the tiles that are in view, the player will see blanks at first that get filled in shortly after. One strategy you can use to resolve this problem is to also load tiles that are slightly out of view; that way, when the player moves, those next tiles will already be pre-loaded while your code starts loading other slightly-out-of-view tiles in preparation for the next moves (no matter what direction the player goes since you can't accurately predict this anyway, especially if the player suddenly sees a dangerous giant spider that likes to eat speed-boosting-boots).
The beauty of using a database to load up on the nearby areas is that you have the option of increasing the size of your world far beyond 100k-by-100k.
For your database, you'll need to have two columns that represent the X and Y positions. If your player can move their character up (e.g., onto a rooftop) or down (e.g., into a dungeon), then you'll need to have a third column that represents the Z position as well.