Book Image

The Artificial Intelligence Infrastructure Workshop

By : Chinmay Arankalle, Gareth Dwyer, Bas Geerdink, Kunal Gera, Kevin Liao, Anand N.S.
Book Image

The Artificial Intelligence Infrastructure Workshop

By: Chinmay Arankalle, Gareth Dwyer, Bas Geerdink, Kunal Gera, Kevin Liao, Anand N.S.

Overview of this book

Social networking sites see an average of 350 million uploads daily - a quantity impossible for humans to scan and analyze. Only AI can do this job at the required speed, and to leverage an AI application at its full potential, you need an efficient and scalable data storage pipeline. The Artificial Intelligence Infrastructure Workshop will teach you how to build and manage one. The Artificial Intelligence Infrastructure Workshop begins taking you through some real-world applications of AI. You’ll explore the layers of a data lake and get to grips with security, scalability, and maintainability. With the help of hands-on exercises, you’ll learn how to define the requirements for AI applications in your organization. This AI book will show you how to select a database for your system and run common queries on databases such as MySQL, MongoDB, and Cassandra. You’ll also design your own AI trading system to get a feel of the pipeline-based architecture. As you learn to implement a deep Q-learning algorithm to play the CartPole game, you’ll gain hands-on experience with PyTorch. Finally, you’ll explore ways to run machine learning models in production as part of an AI application. By the end of the book, you’ll have learned how to build and deploy your own AI software at scale, using various tools, API frameworks, and serialization methods.
Table of Contents (14 chapters)
Preface
4
4. The Ethics of AI Data Storage

Exploring the Collective Knowledge of Databases

This section is all about the implementation of what we've learned in this chapter. So far, we have gone through the nitty-gritty of databases and discussed MySQL for RDBMS and NoSQL databases such as MongoDB and Cassandra. Now, let's take the FashionMart store example and think about a scenario where we have the following schema:

Figure 5.68: Star schema of FashionMart

In a case where the number of daily active users is 1 million and the Sales data is around 5 billion, then performing joins using MySQL between the dimensions will cause serious overhead. But here, the benefit is consistency, so if you want to update a Sales record, then it will be referenced in your next query.

Now, think about solving this use case using MongoDB. If we embedded a Sales entity inside Products by denormalizing the sales data, then it will drastically reduce latency as no data is shuffling or joins over the network...