Oakscale

oakscale

The Oakdale Affair by Edgar Rice Burroughs, is part of the HackerNoon Books Series. Read this book online for free on HackerNoon! : The Oakdale Affair Title : Edgar Rice Burroughs Author : July 11, 2008 [EBook #363] Most recently updated: January 27, 2021 Release date : English Language Table of Links Chapter One About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Edgar Rice Burroughs (2008). The Oakdale Affair. Urbana, Illinois: Project Gutenberg. Retrieved October 2022 https://www.gutenberg.org/cache/epub/363/pg363-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

The Oakdale Affair by Edgar Rice Burroughs - Table of Links

Chateau is pleased to announce our pre-seed financing round led by Hack VC and other angels! What is Chateau? Chateau is a DeFi protocol that brings Wall Street’s private equity and funds investments on-chain. DeFi investors are able to access thousands of private investment opportunities via composable tokens using Chateau. Chateau’s team consists of crypto-native engineers, builders, and seasoned Wall Street veterans spread across Europe, North America and Asia. We believe DeFi can outscale and replace legacy financial systems, but DeFi products need to improve to the point they are 10x better than incumbents for meaningful adoption to occur. Chateau unlocks previously inaccessible investment opportunities for non-US investors. Learning from mistakes from past security token projects, Chateau’s approach is unique in minimizing onboarding and regulatory burdens for issuers, while simultaneously maximizing composability and usability for DeFi native investors. Get Involved Chateau has launched an incentive program for early adopters. Early investors of Chateau’s equity and debt tokens will receive up to 5% of tokens during the token generation event. Today, Chateau allows non-US investors access to a tokenized private credit fund managed by an experienced Wall Street team, as well as over a thousand tokenized private equities such as OpenAI, SpaceX, Anthropic, Byte Dance and Zipline. Chateau is expanding the products investors are able to access on its platform, with plans to launch more equities and funds in the coming months. For more details, email us at contact@chateau.capital. If our mission resonates with you, we’re always looking for talented folks to join our founding team. Reach out at contact@chateau.capital Thank you again to our investors, Alex Pack and Hack VC. Their hands-on help has been invaluable, and we look forward to partnering with them for the long-term. Original tweet and blog post by Hack VC:
https://blog.hack.vc/investing-in-chateau-bringing-composable-private-equities-and-funds-on-chain/ https://x.com/hack_vc/status/1819102732525191667?embedable=true Disclaimer: The information herein is for general information purposes only and does not, and is not intended to, constitute investment advice and should not be used in the evaluation of any investment decision. Such information should not be relied upon for accounting, legal, tax, business, investment or other relevant advice. You should consult your own advisers, including your own counsel, for accounting, legal, tax, business, investment or other relevant advice, including with respect to anything discussed herein.
This post reflects the current opinions of the author and is not made on behalf of Hack VC or Chateau Capital Corp. its affiliates, including any funds managed by Hack VC and does not necessarily reflect the opinions of Hack VC or Chateau Capital Corp. its affiliates, including its general partner affiliates, or any other individuals associated with Hack VC or Chateau Capital Corp. Chateau is pleased to announce our pre-seed financing round led by Hack VC and other angels! Chateau is pleased to announce our pre-seed financing round led by Hack VC and other angels! Chateau Chateau Hack VC Hack VC What is Chateau? Chateau is a DeFi protocol that brings Wall Street’s private equity and funds investments on-chain. DeFi investors are able to access thousands of private investment opportunities via composable tokens using Chateau. Chateau’s team consists of crypto-native engineers, builders, and seasoned Wall Street veterans spread across Europe, North America and Asia. We believe DeFi can outscale and replace legacy financial systems, but DeFi products need to improve to the point they are 10x better than incumbents for meaningful adoption to occur. Chateau unlocks previously inaccessible investment opportunities for non-US investors. Learning from mistakes from past security token projects, Chateau’s approach is unique in minimizing onboarding and regulatory burdens for issuers, while simultaneously maximizing composability and usability for DeFi native investors. Get Involved Chateau has launched an incentive program for early adopters. Early investors of Chateau’s equity and debt tokens will receive up to 5% of tokens during the token generation event. Today, Chateau allows non-US investors access to a tokenized private credit fund managed by an experienced Wall Street team, as well as over a thousand tokenized private equities such as OpenAI, SpaceX, Anthropic, Byte Dance and Zipline. Chateau is expanding the products investors are able to access on its platform, with plans to launch more equities and funds in the coming months. For more details, email us at contact@chateau.capital. If our mission resonates with you, we’re always looking for talented folks to join our founding team. Reach out at contact@chateau.capital Thank you again to our investors, Alex Pack and Hack VC. Their hands-on help has been invaluable, and we look forward to partnering with them for the long-term. Original tweet and blog post by Hack VC: https://blog.hack.vc/investing-in-chateau-bringing-composable-private-equities-and-funds-on-chain/ https://blog.hack.vc/investing-in-chateau-bringing-composable-private-equities-and-funds-on-chain/ https://x.com/hack_vc/status/1819102732525191667?embedable=true https://x.com/hack_vc/status/1819102732525191667?embedable=true Disclaimer: The information herein is for general information purposes only and does not, and is not intended to, constitute investment advice and should not be used in the evaluation of any investment decision. Such information should not be relied upon for accounting, legal, tax, business, investment or other relevant advice. You should consult your own advisers, including your own counsel, for accounting, legal, tax, business, investment or other relevant advice, including with respect to anything discussed herein. This post reflects the current opinions of the author and is not made on behalf of Hack VC or Chateau Capital Corp. its affiliates, including any funds managed by Hack VC and does not necessarily reflect the opinions of Hack VC or Chateau Capital Corp. its affiliates, including its general partner affiliates, or any other individuals associated with Hack VC or Chateau Capital Corp. Disclaimer : The information herein is for general information purposes only and does not, and is not intended to, constitute investment advice and should not be used in the evaluation of any investment decision. Such information should not be relied upon for accounting, legal, tax, business, investment or other relevant advice. You should consult your own advisers, including your own counsel, for accounting, legal, tax, business, investment or other relevant advice, including with respect to anything discussed herein. Disclaimer This post reflects the current opinions of the author and is not made on behalf of Hack VC or Chateau Capital Corp. its affiliates, including any funds managed by Hack VC and does not necessarily reflect the opinions of Hack VC or Chateau Capital Corp. its affiliates, including its general partner affiliates, or any other individuals associated with Hack VC or Chateau Capital Corp.

Announcing Chateau’s Pre-Seed Financing Round Led by Hack VC

হ্যাক ভিসি এর নেতৃত্বে Chateau-এর প্রাক-বীজ অর্থায়ন রাউন্ডের ঘোষণা

Ankündigung der von Hack VC geleiteten Pre-Seed-Finanzierungsrunde von Chateau

Anuncio de la ronda de financiación previa a la semilla de Chateau dirigida por Hack VC

Annonce du cycle de financement de pré-amorçage de Chateau mené par Hack VC

हैक वीसी के नेतृत्व में शैटॉ के प्री-सीड फाइनेंसिंग राउंड की घोषणा

Hack VCが主導するChateauのプレシード資金調達ラウンドを発表

Hack VC가 주도하는 Chateau의 사전 시드 파이낸싱 라운드 발표

Anunciando a rodada de financiamento pré-semente do Chateau liderada por Hack VC

Объявление о раунде предварительного финансирования Chateau под руководством Hack VC

Chateau'nun Hack VC Liderliğindeki Tohum Öncesi Finansman Turunu Duyurdu

Thông báo Vòng cấp vốn trước hạt giống của Chateau do Hack VC dẫn đầu

Chateau 宣布完成由 Hack VC 领投的种子前融资

In the presentation below, Niklas Kunkel, Oracle Core Unit Facilitator at MakerDAO, talks about the role that oracles play in bridging real world assets on-chain. https://youtu.be/rFv4FWMtlRE?embedable=true Below are further explanations of key points highlighted during his talk. Introduction to MakerDAO & Stablecoins MakerDAO is a decentralized autonomous organization (DAO) that guides the development of the Maker protocol. The Maker protocol is built on Ethereum and makes use of smart contracts to generate and maintain their stablecoin, Dai. Stablecoins are cryptocurrencies that maintain a stable value by being pegged to other stable assets or by using algorithms. Stablecoins generally fall into the following categories; Stablecoins that are backed 1:1 by one or more currencies such as the US dollar and Euro. Oneexample of a fiat-backed stablecoin is . Fiat-backed: USDT Stablecoins that are backed by other cryptocurrencies like Ether (ETH). Since cryptocurrencies are more volatile than fiat currency, crypto-backed stablecoins are usually overcollateralized. This means that instead of being backed 1:1, the amount in reserves would be higher than the value of the stablecoins in circulation. Crypto-backed stablecoins are issued on-chain using smart contracts. is an example of a crypto-backed stablecoin. Crypto-backed: Dai Stablecoins that are backed 1:1 by physical commodities such as gold. is an example of a commodity-backed stablecoin. Commodity-backed: Paxos Gold Stablecoins that make use of algorithms to manage the circulating supply based on market prices. is one example of an algorithmic stablecoin. Algorithmic: Ampleforth According to Niklas, the Maker team developed one of the first oracles on Ethereum. Back in 2014 when they were developing the protocol, there were no oracle solutions available that suited their needs. The team decided to build their own oracle with the intention of switching to another service later on. However, nothing suitable was ever developed and MakerDAO still uses their own oracle today. Niklas is currently responsible for leading the oracle unit of the Maker protocol. DeFi, DEXs & CEXs Decentralized Finance (DeFi) has faced unprecedented growth over the last 2 years. As a result, Decentralized Exchanges (DEXs) have also seen a surge in the amount of usage, with volumes now with centralized exchanges (CEXs) like Coinbase. competing DEXs are peer-to-peer marketplaces built on chain that enable the permissionless trading of assets. This is done by creating liquidity pools and incentivizing users to deposit assets to these pools through a process called yield farming. refers to the process where users deposit cryptocurrency assets into liquidity pools in exchange for trading fees. Assets are automatically swapped between traders and liquidity pools using smart contracts. While CEXs have Order Books that match bids to asks, Automated Market Makers, AMMs, are essential to  DEXs like Uniswap or Curve, acting as the mechanism that sets the price of tokens in a liquidity pool. Yield farming Hyperreflexivity of DeFi In his presentation, Niklas describes DeFi as being “hyperreflexive” in nature. He illustrates this point by describing the following scenario; During bull markets, as the price of popular cryptocurrency tokens like Bitcoin and Ethereum go up, the demand for also increases. As a result, the yield that can be earned for lending also goes up in order to incentivize users to provide liquidity for this leverage. This leads to a large amount of capital flowing into DeFi protocols. leverage As more and more users start , the Total Value Locked ( ) on AMMs like and go up. This ends up serving as a positive feedback loop – a higher TVL attracts more and more users to put their capital into the protocol. The inherent problem with this hyperreflexivity is that when asset prices drop, all the feedback loops explained previously that help DeFi thrive go in reverse, and capital flows out just as quickly as it flowed in. yield farming TVL Uniswap Curve Connecting DeFi to the Real World According to Niklas, in order for DeFi to grow beyond this hyperreflexive bubble, it must be connected to the real world. There are over 100 trillion dollars worth of assets in the traditional financial (TradFi) system versus approximately 100 billion dollars worth in DeFi. Even in a bear market, there is a chance that DeFi can continue to grow by absorbing these Real World Assets (RWAs). The growth from that can outscale any negative macroeconomic pressures. Absorbing RWAs into the DeFi ecosystem would also lower overhead costs in traditional markets by minimizing the need for middlemen typically required in traditional finance. According to Niklas, DAI could be a benefactor of this as the most time and stress tested decentralized stablecoin. One problem with connecting RWAs to DeFi is that the majority of these assets are highly illiquid, meaning they are not actively traded on markets. It is also difficult to derive fair market values for these assets. Financial information pertaining to these assets are heavily censored, with limited information available about the relevant counterparties. If the asset originators are the only source of the data, there is a moral hazard involved as they would be incentivized to report market data that benefits themselves. Implementing RWA oracles In the framework prescribed by Niklas, in order to implement RWA oracles, 3 main players are required – The asset originator, an auditor and the data consumer, who is the ultimate end user consuming the oracle data. Asset originators should submit underlying data on the asset, and not the price. They should not be setting the price of an asset themselves. Rather, they should be submitting data that can be utilized to derive a fair price.  Asset originators are incentivized to provide valid data because an auditor is going to check that this data is correct. If the auditor concludes otherwise, the asset originator can get their credit ratings slashed. Nevertheless, asset originators are assumed to be adversarial and will try to obtain an edge where possible. The role of an auditor is to validate that the data supplied by the asset originator is legitimate. The data consumer will define a data model for how prices should be derived. Auditors then validate the data inputs provided by the asset originator, and plug these inputs into the aforementioned data model. In this model, it is important to note that it is the data consumer who is paying the auditor for their services. The auditor and the asset originator cannot be morally aligned, or aligned in any business sense. A good counterexample would be this from ‘The Big Short’, where the ‘asset originator’ is the one giving business to the ‘auditor’, incentivizing the auditor to fake the validity of the data inputs. scene MakerDAO & RWA Maker has begun the absorption of RWAs into the DeFi ecosystem through a series of partnerships stated below: – MakerDAO is helping to provide short term mortgages for people who want to buy and sell homes quickly for a profit. New silver – Credit tenant lease financing. MakerDAO provides capital, so 6S Capital can finance the construction of buildings when they have guaranteed tenants. 6S Capital – A financier which allows MakerDAO to divert USDC on their balance sheet into US treasuries. US treasuries are extremely liquid, resulting in higher yields with lower risks involved. Monetalis – Covered bonds backed by home loans. Forge wants to 40 million Euros worth of bonds, proposing a 30 million DAI debt facility. Societe Generale (Forge) finance In the current crypto market, there are many who believe that there is a lot of value to be extracted from traditional markets which could help offset some of the revenue lost from crypto. While embracing RWAs could help protocols like Maker maintain its position as a leading DeFi protocol despite market conditions, there is still some concern over the centralized aspect of traditional assets. In his interview with , manager of Real World Assets at MakerDAO, TJ Ragsdale, explained that “the goal is really to take advantage of all the value that lives out there in the real world, and as Maker — with our unique position in the market, build in transparency and determinism that we all love about crypto into those traditional systems.” Blockworks The Blockchain Oracle Summit was the world’s first conference to fully focus on the importance of oracles and the potential value they bring to DeFi and beyond. Leading oracle experts from around the world gathered in Berlin to take deep-dives into their work. Find out more about MakerDAO: MakerDAO Documentation MakerDAO Twitter MakerDAO Discord MakerDAO Youtube Niklas Kunkel Twitter Niklas Kunkel Github

How Oracles Act a Catalyst in Bridging Real World Assets On-Chain

How I Cloned a Simple VSCode Using Tauri and ReactJS

The house on the hill showed lights

Mission-critical applications require . The goal of high availability is to provide users with consistent access to services or resources, minimizing the chances of interruption. is a specific mechanism used to achieve high availability. It involves automatically detecting the failure of a system component (like a server, network, or database) and immediately switching operations to a standby component without human intervention. This increases resiliency. high availability Automatic failover MariaDB MaxScale is a database proxy that includes features for high availability. In this article, I'll show you how you can try it out with an application implemented in Java and Svelte. online store simulator Architecture The following diagram shows the architecture of the demo application: A web application developed with JavaScript and the Svelte framework makes HTTP requests to a Java backend. The backend answers with that the frontend uses to update the user interface on the browser. server-sent events The backend is implemented with and connects to a database cluster using (reactive). The backend logic is, in short, a simulation of reads and writes to an online store database. The simulation is parameterized, and the user can adjust: Spring Boot MariaDB R2DBC How many reads to the database per minute. Product visits per minute: How many writes to the database per minute. Orders per minute: Write amplification. Products per order: How many seconds until a request to the database is considered failed. Timeout in milliseconds: The database cluster is front-ended by a called MaxScale. This proxy makes the cluster look like a single logical database to the Java backend. MaxScale also performs read/write splitting (sending writes to the primary MariaDB server and reads to replicas), as well as load-balancing of reads among replica servers using a configurable algorithm. Data is automatically replicated from the primary to the replica database servers. database proxy Building the Docker images from source I have prepared custom Docker images for every component in the simulator. You can either build the images from the source (optional) or use the already built and published images from Docker Hub. If you decide to build the images yourself, you can find the source code on GitHub: Custom images for easy deployment of replicated MariaDB topologies with MaxScale. These images are suitable only for demo applications. Use the for production deployments. : MariaDB deployments DO NOT USE THESE IN PRODUCTION! official MariaDB Docker images The backend application that connects to the database cluster. : Backend application The frontend application that makes simulation configuration requests to the backend and receives events to show the simulation result. : Frontend application Each repository has Dockerfiles that you can use to build your own Docker images. For example, to build the backend application image, run: docker build --tag alejandrodu/online-store-simulator-java-backend . Running the simulation All the services can be started using the following Docker Compose file ( ): docker-compose.yml version: "3.9"
services:
  server-1:
    container_name: server-1
    image: alejandrodu/mariadb
    ports:
      - "3306:3306"
    environment:
      - MARIADB_CREATE_DATABASE=demo
      - MARIADB_CREATE_USER=user:Password123!
      - MARIADB_CREATE_REPLICATION_USER=replication_user:ReplicationPassword123!
      - MARIADB_CREATE_MAXSCALE_USER=maxscale_user:MaxScalePassword123!

  server-2:
    container_name: server-2
    image: alejandrodu/mariadb
    ports:
      - "3307:3306"
    environment:
      - MARIADB_REPLICATE_FROM=replication_user:ReplicationPassword123!@server-1:3306

  server-3:
    container_name: server-3
    image: alejandrodu/mariadb
    ports:
      - "3308:3306"
    environment:
      - MARIADB_REPLICATE_FROM=replication_user:ReplicationPassword123!@server-1:3306

  maxscale:
    container_name: maxscale
    image: alejandrodu/mariadb-maxscale
    command: --admin_host 0.0.0.0 --admin_secure_gui false
    ports:
      - "4000:4000"
      - "8989:8989"
      - "27017:27017"
    environment:
      - MAXSCALE_USER=maxscale_user:MaxScalePassword123!
      - MARIADB_HOST_1=server-1 3306
      - MARIADB_HOST_2=server-2 3306
      - MARIADB_HOST_3=server-3 3306
    healthcheck:
      test: ["CMD", "maxctrl", "list", "servers"]
      interval: 5s
      timeout: 10s
      retries: 5

  java-backend:
    container_name: java-backend
    image: alejandrodu/online-store-simulator-java-backend
    ports:
      - "8080:8080"
    environment:
    - spring.r2dbc.url=r2dbc:mariadb://maxscale:4000/demo
    - spring.r2dbc.username=user
    - spring.r2dbc.password=Password123!
    - spring.liquibase.url=jdbc:mariadb://maxscale:4000/demo
    - spring.liquibase.user=user
    - spring.liquibase.password=Password123!
    depends_on:
      maxscale:
        condition: service_healthy

  svelte-frontend:
    container_name: svelte-fronted
    image: alejandrodu/online-store-simulator-svelte-frontend
    ports:
      - "5173:80"
    environment:
      - BACKEND_URL=http://java-backend:8080 Move to the directory in which the Docker Compose file is, and start the services in detached mode as follows: docker compose up -d Configuring MaxScale Before you start the simulation, configure MaxScale for transaction replay. Also, timeouts should be adjusted to make the simulation more interesting. Navigate to and log into the UI using: http://localhost:8989/ Username: admin Password: mariadb You'll see a dashboard with the MariaDB cluster state. There's a primary server ( ), and two replicas ( and ). Replication is already configured from (primary) to and (replicas). All servers should be up and running. server-1 server-2 server-3 server-1 server-2 server-3 Click on and then on the icon to enable parameter editing. Set the following parameters: mdb_monitor pencil ( ): This enables automatic failover. When a MariaDB server is down, MaxScale selects a replica server and reconfigures it as the new primary so that writes can continue to happen. auto_failover true ( ): This enables the automatic rejoin of recovered servers. When a failed server is up again, MaxScale detects it and configures it as an available replica server. auto_rejoin true ( ): Sets the number of monitor (a component in MaxScale that checks server status) iterations required for a server to be down in order to activate the failover process. We set a value of to make sure the failover starts immediately after failure. failcount 1 1 ( ): Connection timeout for monitor connections. We set a low value (one second) to quickly activate failover for this demo. backend_connect_timeout 1000 ( ): Read timeout for monitor connections. backend_read_timeout 1000 ( ): Write timeout for monitor connections. backend_write_timeout 1000 ( ): Primary failure timeout. master_failure_timeout 1000 ( ): How often the servers are monitored. monitor_interval 1000 ⚠️ These values are appropriate for this demo but very likely not the best for production environments! WARNING: Once the parameters are set, click on and . Done Editing Confirm You also need to enable transaction replay, which automatically re-executes failed in-flight transactions on servers that went down just after a SQL statement was routed. This is a useful feature for software developers since it prevents the need for coding failure cases and transaction retry. On the main menu, click on and then on any of the links in the list of servers. Edit the parameters as follows: Dashboard query_router_service ( ): Activates automatic retry of failed transactions. transaction_replay true ( ): Same as the previous when a deadlock occurs. transaction_replay_retry_on_deadlock true ( ): Same as the previous when a checksum mismatch occurs. transaction_replay_retry_on_mismatch true Once the parameters are set, click on and . Done Editing Confirm Starting the simulation With everything configured, you can start the simulation. Navigate to and configure the following parameters (names are, I hope, self-explanatory): http://localhost:5173/ Product visits per minute: 6000 Orders per minute: 60 Timeout in milliseconds: 8000 But before you start the simulation, you need to create the products for the online store. Click on | . Leave the default values and click on . You should see the UI updating as products are created in the database. Data Create products... Create Now, you can finally click on and see the simulation in action. Start Simulating a server failure At this point, the primary server is handling writes (orders). What happens if you stop that server? In the command line run: docker stop server-1 Depending on multiple factors, you might get some "disappointed visitors" or even a few "missed opportunities" in the simulator. Or maybe you don't get any at all! Product visits (reads) and orders (writes) continue to happen, thanks to MaxScale. Without automatic failover, you have to reconfigure everything manually, which results in more offline time, many disappointed visitors, and missed opportunities! Start the failed server: docker start server-1 Go to the MaxScale ( ) and check that is now a functioning replica. Dashboard http://localhost:8989/ server-1 You can perform a manual to make the primary server again. Click on and then mouse hover over the section. Click on the icon and select . Click and check again in the that the new primary server is . switchover server-1 mdb_monitor MASTER pencil server-1 Swap Dashboard server-1 Conclusion Automatic failover is only one of the components in highly available systems. You can use a database proxy like MaxScale to set up automatic failover, as well as other components such as load-balancing, query routing, transaction retry, topology isolation, and more. Check out the documentation at . https://mariadb.com/kb/en/maxscale/ Also published . here

Achieving High Availability with MariaDB MaxScale

Advances in Photocatalytic Materials through SALSA

A New Framework for Trustworthy AI Deductive Reasoning

CulturaX: A High-Quality, Multilingual Dataset for LLMs - Conclusion and References

Redis is mainly used as an application cache or a quick-response database. But wait, you can always create a cache in a relational database as follows: CREATE TABLE cache(
    ´key´ VARCHAR(64) PRIMARY KEY,
    value VARCHAR(255) NOT NULL,
    last_updated TIMESTAMP
        DEFAULT CURRENT_TIMESTAMP
        ON UPDATE CURRENT_TIMESTAMP
); Moreover, with MariaDB, you can pick one from the many available storage engines. For example, if you want to store the previous cache table in memory, simply use the MEMORY storage engine: CREATE TABLE cache(
    ...
) ENGINE=MEMORY; When you configure the cache table to use the MEMORY storage engine, its data will reside entirely in RAM. This is interestingly similar to how Redis operates, keeping data in memory for low-latency access. This looks great and it definitely has its benefits. However, there are a few nuances that are worth exploring. Example Use Case Let’s say you have a web application that needs to track session IDs. Using a MariaDB MEMORY table sounds like a good idea here—there’s potential for reducing the load on your primary databases and improving response times for your users. Here's how you could implement such a cache using MariaDB’s MEMORY storage engine: CREATE OR REPLACE TABLE users_cache (
	user_name VARCHAR(50) NOT NULL PRIMARY KEY REFERENCES users(id),
	session_id VARCHAR(50),
	last_updated DATETIME NOT NULL
		DEFAULT CURRENT_TIMESTAMP
		ON UPDATE CURRENT_TIMESTAMP
) ENGINE=MEMORY; Insertion into this table would typically occur whenever a user logs in. But generalizing a bit more, insertion in a cache could happen every time you read data stored on disk-based tables. We’ll use the latter approach and assume that permanently storing session IDs is a business requirement so that we can do more experiments. In any case, you can set up a background job to refresh this cache periodically or invalidate it when the underlying data changes. Cache Invalidation and Management There are several ways to handle cache invalidation with MariaDB. For example, you can set a limited row-based lifespan (through a column for expiration time) and use event schedulers to clear or update cached data at fixed intervals. Here’s an example: CREATE OR REPLACE EVENT ev_remove_stale_user_cache_entries
    ON SCHEDULE EVERY 20 MINUTE DO
		DELETE FROM users_cache
		WHERE NOW() > last_updated + INTERVAL 2 HOUR; For testing, you can use different intervals. For example EVERY 1 SECOND and INTERVAL 20 SECOND. Also, remember to enable MariaDB’s event scheduler by setting the event_scheduler configuration property or, for testing, by running: SET GLOBAL event_scheduler = ON; If you want to try this out, you can find a complete example on GitHub. Or watch the short video demoing the example in action. Pros and cons Although using the MEMORY storage engine can speed up data retrieval times, as always, this depends on the exact use case—you should test this configuration with your applications before making decisions. In particular, it’s important to be aware that MEMORY performs table-wide locks. This means that it might not be well-suited when you need to update the cache more frequently than you read it. Or in other words, using the MEMORY storage engine is a good option for data that needs to be accessed frequently and updated infrequently. A key advantage of using the MEMORY engine is when your app needs to mix cache data with data in tables of a relational database, for example, during a single HTTP request. Imagine an app that processes user information updates. Each update might involve writing to a cache and simultaneously updating a relational record. This would require two different accesses to two different databases. With MariaDB, you can handle this in a single database using SQL. This eliminates the overhead and complexity of managing separate data stores and coordinating between them. Here’s a simplified example of how such an operation could look: SET @data = "other data";
UPDATE users SET data = @data WHERE id = 123;
REPLACE INTO users_cache (user_id, data) VALUES (123, @data); In this example, the user's data columns in both the users and the user_cache tables are updated in a single call to the database. Keep in mind that the MEMORY storage engine is not transactional, which is less important when you compare it with a cache that lives in a completely different database technology than your operational database anyway. An additional and obvious but important advantage of using the MEMORY engine is that you can remove persistence-polyglot logic from your app. If your team is already familiar with SQL, MariaDB provides a seamless experience without the need to learn new syntax or juggle another technology stack. How Does It Stack Up Against Redis? While Redis is a powerful tool for handling simple data structures like strings, hashes, lists, sets, and sorted sets directly in-memory, MariaDB's MEMORY engine handles complex queries more naturally because it supports the full power of SQL and relational database systems. This means you can perform joins, subqueries, and even complex transactions, which are not as straightforward in Redis. Now, there’s also the question of scalability. Especially horizontal scalability. This involves adding more nodes to a system to distribute load and increase capacity without interrupting service. Both Redis and MariaDB offer robust solutions, but their mechanisms are different. Redis achieves horizontal scalability primarily through sharding, where data is partitioned across multiple Redis instances. This can be configured manually or managed via Redis Cluster, which handles sharding and provides high availability through failover and replication processes. Redis Cluster supports up to 1000 nodes, which allows it to scale massively. This model is particularly effective for applications requiring ultra-fast operations and high throughput on simple data structures. MariaDB offers a somewhat similar approach to scalability. And you probably guessed it—this is achieved through a storage engine. The Spider engine partitions table data across multiple MariaDB nodes, treating them as one logical entity. This enables querying and updating data across various physical servers seamlessly as if they were on a single local server. The Spider engine supports SQL and transactional data operations so you can run complex queries when you need. It’s useful for large database environments where data distribution is essential for performance and management to meet the demands of large-scale applications. Durability and Persistence One difference to consider is that the MEMORY storage engine in MariaDB does not offer data persistence after the server restarts. Data stored in MEMORY tables is volatile; it's cleared when the database restarts, much like Redis in its default configuration. If persistence is crucial, you might consider using MariaDB's Aria or InnoDB engines for caching. In fact, InnoDB has excellent performance thanks to its cache mechanism, which reduces the load on primary nodes. Final Thoughts Switching from Redis to MariaDB for caching might not suit every project, but it's a viable option for those looking to streamline their technology stack or leverage their existing SQL expertise. It provides an easy way to implement caching solutions with tools you already know and reduces the overhead of managing additional systems. Plus, for those looking for a middle ground, MariaDB can also serve as a complementary caching layer alongside Redis, taking advantage of both systems' strengths. Moreover, you can leverage Redis as a cache for MariaDB MaxScale. Try MariaDB and set up your own in-memory cache with the MEMORY storage engine. Experience how it fits with your existing SQL knowledge. I have created a simple plain-text file with detailed instructions and code that you can run to see a cache in action using only SQL! So all you need is to connect to your MariaDB server (spin one up quickly using Docker if you don’t have one running already) and run the commands in any SQL client compatible with MariaDB (most of them are). Here you can see the demo in action: If you have questions or want to share your experience, don’t hesitate to join the MariaDB Community Slack and let us know! Redis is mainly used as an application cache or a quick-response database. But wait, you can always create a cache in a relational database as follows: CREATE TABLE cache(
    ´key´ VARCHAR(64) PRIMARY KEY,
    value VARCHAR(255) NOT NULL,
    last_updated TIMESTAMP
        DEFAULT CURRENT_TIMESTAMP
        ON UPDATE CURRENT_TIMESTAMP
); CREATE TABLE cache(
    ´key´ VARCHAR(64) PRIMARY KEY,
    value VARCHAR(255) NOT NULL,
    last_updated TIMESTAMP
        DEFAULT CURRENT_TIMESTAMP
        ON UPDATE CURRENT_TIMESTAMP
); Moreover, with MariaDB , you can pick one from the many available storage engines . For example, if you want to store the previous cache table in memory, simply use the MEMORY storage engine : MariaDB storage engines cache MEMORY storage engine CREATE TABLE cache(
    ...
) ENGINE=MEMORY; CREATE TABLE cache(
    ...
) ENGINE=MEMORY; When you configure the cache table to use the MEMORY storage engine , its data will reside entirely in RAM. This is interestingly similar to how Redis operates, keeping data in memory for low-latency access. This looks great and it definitely has its benefits. However, there are a few nuances that are worth exploring. cache MEMORY storage engine Example Use Case Let’s say you have a web application that needs to track session IDs. Using a MariaDB MEMORY table sounds like a good idea here—there’s potential for reducing the load on your primary databases and improving response times for your users. Here's how you could implement such a cache using MariaDB’s MEMORY storage engine: primary databases CREATE OR REPLACE TABLE users_cache (
	user_name VARCHAR(50) NOT NULL PRIMARY KEY REFERENCES users(id),
	session_id VARCHAR(50),
	last_updated DATETIME NOT NULL
		DEFAULT CURRENT_TIMESTAMP
		ON UPDATE CURRENT_TIMESTAMP
) ENGINE=MEMORY; CREATE OR REPLACE TABLE users_cache (
	user_name VARCHAR(50) NOT NULL PRIMARY KEY REFERENCES users(id),
	session_id VARCHAR(50),
	last_updated DATETIME NOT NULL
		DEFAULT CURRENT_TIMESTAMP
		ON UPDATE CURRENT_TIMESTAMP
) ENGINE=MEMORY; Insertion into this table would typically occur whenever a user logs in. But generalizing a bit more, insertion in a cache could happen every time you read data stored on disk-based tables. We’ll use the latter approach and assume that permanently storing session IDs is a business requirement so that we can do more experiments. In any case, you can set up a background job to refresh this cache periodically or invalidate it when the underlying data changes. Cache Invalidation and Management There are several ways to handle cache invalidation with MariaDB. For example, you can set a limited row-based lifespan (through a column for expiration time) and use event schedulers to clear or update cached data at fixed intervals. Here’s an example: event schedulers CREATE OR REPLACE EVENT ev_remove_stale_user_cache_entries
    ON SCHEDULE EVERY 20 MINUTE DO
		DELETE FROM users_cache
		WHERE NOW() > last_updated + INTERVAL 2 HOUR; CREATE OR REPLACE EVENT ev_remove_stale_user_cache_entries
    ON SCHEDULE EVERY 20 MINUTE DO
		DELETE FROM users_cache
		WHERE NOW() > last_updated + INTERVAL 2 HOUR; For testing, you can use different intervals. For example EVERY 1 SECOND and INTERVAL 20 SECOND . Also, remember to enable MariaDB’s event scheduler by setting the event_scheduler configuration property or, for testing, by running: EVERY 1 SECOND INTERVAL 20 SECOND event scheduler event_scheduler SET GLOBAL event_scheduler = ON; SET GLOBAL event_scheduler = ON; If you want to try this out, you can find a complete example on GitHub . Or watch the short video demoing the example in action . complete example on GitHub watch the short video demoing the example in action Pros and cons Although using the MEMORY storage engine can speed up data retrieval times, as always, this depends on the exact use case—you should test this configuration with your applications before making decisions. In particular, it’s important to be aware that MEMORY performs table-wide locks . This means that it might not be well-suited when you need to update the cache more frequently than you read it. Or in other words, using the MEMORY storage engine is a good option for data that needs to be accessed frequently and updated infrequently . MEMORY performs table-wide locks the MEMORY storage engine is a good option for data that needs to be accessed frequently and updated infrequently A key advantage of using the MEMORY engine is when your app needs to mix cache data with data in tables of a relational database , for example, during a single HTTP request. Imagine an app that processes user information updates. Each update might involve writing to a cache and simultaneously updating a relational record. This would require two different accesses to two different databases. With MariaDB, you can handle this in a single database using SQL. This eliminates the overhead and complexity of managing separate data stores and coordinating between them. Here’s a simplified example of how such an operation could look: mix cache data with data in tables of a relational database SET @data = "other data";
UPDATE users SET data = @data WHERE id = 123;
REPLACE INTO users_cache (user_id, data) VALUES (123, @data); SET @data = "other data";
UPDATE users SET data = @data WHERE id = 123;
REPLACE INTO users_cache (user_id, data) VALUES (123, @data); In this example, the user's data columns in both the users and the user_cache tables are updated in a single call to the database. Keep in mind that the MEMORY storage engine is not transactional , which is less important when you compare it with a cache that lives in a completely different database technology than your operational database anyway. data users user_cache the MEMORY storage engine is not transactional transactional An additional and obvious but important advantage of using the MEMORY engine is that you can remove persistence-polyglot logic from your app . If your team is already familiar with SQL , MariaDB provides a seamless experience without the need to learn new syntax or juggle another technology stack. remove persistence-polyglot logic from your app SQL How Does It Stack Up Against Redis? While Redis is a powerful tool for handling simple data structures like strings, hashes, lists, sets, and sorted sets directly in-memory, MariaDB's MEMORY engine handles complex queries more naturally because it supports the full power of SQL and relational database systems. This means you can perform joins, subqueries, and even complex transactions, which are not as straightforward in Redis. Redis is a powerful tool for handling simple data structures MariaDB's MEMORY engine handles complex queries more naturally Now, there’s also the question of scalability . Especially horizontal scalability. This involves adding more nodes to a system to distribute load and increase capacity without interrupting service. Both Redis and MariaDB offer robust solutions, but their mechanisms are different. scalability Redis achieves horizontal scalability primarily through sharding , where data is partitioned across multiple Redis instances. This can be configured manually or managed via Redis Cluster, which handles sharding and provides high availability through failover and replication processes. Redis Cluster supports up to 1000 nodes, which allows it to scale massively. This model is particularly effective for applications requiring ultra-fast operations and high throughput on simple data structures. Redis achieves horizontal scalability primarily through sharding MariaDB offers a somewhat similar approach to scalability . And you probably guessed it—this is achieved through a storage engine. The Spider engine partitions table data across multiple MariaDB nodes, treating them as one logical entity. This enables querying and updating data across various physical servers seamlessly as if they were on a single local server. The Spider engine supports SQL and transactional data operations so you can run complex queries when you need. It’s useful for large database environments where data distribution is essential for performance and management to meet the demands of large-scale applications. MariaDB offers a somewhat similar approach to scalability Spider engine Durability and Persistence One difference to consider is that the MEMORY storage engine in MariaDB does not offer data persistence after the server restarts. Data stored in MEMORY tables is volatile ; it's cleared when the database restarts, much like Redis in its default configuration. If persistence is crucial, you might consider using MariaDB's Aria or InnoDB engines for caching. In fact, InnoDB has excellent performance thanks to its cache mechanism, which reduces the load on primary nodes. Data stored in MEMORY tables is volatile Aria InnoDB cache Final Thoughts Switching from Redis to MariaDB for caching might not suit every project, but it's a viable option for those looking to streamline their technology stack or leverage their existing SQL expertise. It provides an easy way to implement caching solutions with tools you already know and reduces the overhead of managing additional systems. Plus, for those looking for a middle ground, MariaDB can also serve as a complementary caching layer alongside Redis, taking advantage of both systems' strengths. Moreover, you can leverage Redis as a cache for MariaDB MaxScale . leverage Redis as a cache MariaDB MaxScale Try MariaDB and set up your own in-memory cache with the MEMORY storage engine. Experience how it fits with your existing SQL knowledge. I have created a simple plain-text file with detailed instructions and code that you can run to see a cache in action using only SQL! So all you need is to connect to your MariaDB server (spin one up quickly using Docker if you don’t have one running already) and run the commands in any SQL client compatible with MariaDB (most of them are). Here you can see the demo in action: plain-text file with detailed instructions and code If you have questions or want to share your experience, don’t hesitate to join the MariaDB Community Slack and let us know! MariaDB Community Slack

Leveraging MariaDB’s MEMORY Storage Engine: Efficient Caching and Performance Optimization

Stories, News & Mentions about OAKSCALE

Oakscale’s Stories on HackerNoon