RR 314 DynamoDB on Rails with Chandan Jhunjhunwal
RR 314 DynamoDB on Rails with Chandan Jhunjhunwal
Today's Ruby Rogues podcast features DynamoDB on Rails with Chandan Jhunjhunwal. DynamoDB is a NoSQL database that helps your team solve managing infrastructure issues like setup, costing and maintenance. Take some time to listen and know more about DynamoDB![00:02:18] – Introduction to Chandan JhunjhunwalChanchan Jhunjhunwal is an owner of Faodail Technology, which is currently helping many startups for their web and mobile applications. They started from IBM, designing and building scalable mobile and web applications. He mainly worked on C++ and DB2 and later on, worked primarily on Ruby on Rails.
Questions for Chandan
[00:04:05] – Introduction to DynamoDB on RailsI would say that majority of developers work in PostgreSQL, MySQL or other relational database. On the other hand, Ruby on Rails is picked up by many startup or founder for actually implementing their ideas and bringing them to scalable products. I would say that more than 80% of developers are mostly working on RDBMS databases. For the remaining 20%, their applications need to capture large amounts of data so they go with NoSQL. In NoSQL, there are plenty of options like MongoDB, Cassandra, or DynamoDB. When using AWS, there’s no provided MongoDB. With Cassandra, it requires a lot of infrastructure setup and costing, and you’ll have to have a team which is kind of maintaining it on a day to day basis. So DynamoDB takes all those pain out of your team and you no longer have to focus on managing the infrastructure.[00:07:35] – Is it a good idea to start with a regular SQL database and then, switch to NoSQL database or is it better to start with NoSQL database from day one?It depends on a couple of factors. For many of the applications, they start with RDBMS because they just want to get some access, and probably switch to something like NoSQL. First, you have to watch the incoming data and their capacity. Second is familiarity because most of the developers are more familiar with RDBMS and SQL queries. For example, you have a feed application, or a messaging application, where you know that there will be a lot of chat happening and you’d expect that you’re going to take a huge number of users. You can accommodate that in RDBMS but I would probably not recommend that.[00:09:30] Can I use DynamoDB as a caching mechanism or cache store?I would not say replacement, exactly. On those segments where I could see that there’s a lot of activity happening, I plugged in DynamoDB. The remaining part of the application was handled by RDBMS. In many applications, what I’ve seen is that they have used a combination of them.[00:13:05] How do you decide if you actually want to use DynamoDB for all the data in your system?The place where we say that this application is going to be picked from day one is where the number of data which will be coming will increase. It also depends on the development team that you have if they’re familiar with DynamoDB, or any other NoSQL databases.[00:14:50] Is DynamoDB has document store or do you have of columns?You can say key value pairs or document stores. The terminologies are just different and the way you design the database. In DynamoDB, you have something like hash key and range key.[00:22:10] – Why don’t we store images in the database?I would say that there are better places to store the, which is faster and cheaper. There are better storage like CDN or S3. Another good reason is that if you want to fetch a proper size of image based on the user devices screen, resizing and all of the stuff inside the database could be cumbersome. You’ll repeat adding different columns where we’ll be storing those different sizes of images.[00:24:40] – Is there a potentially good reason for NoSQL database as your default go-to data store?If you have some data, which is complete unstructured, if you try to store back in RDBMS, it will be a pain. If we talk about the kind of media which gets generated in our day to day life, if you try to model them in a relational database, it will be pretty painful and eventually, there will be a time when you don’t know how to create correlations.[00:28:30] – Horizontally scalable versus vertically scalableIn vertically scalable, when someone posts, we keep adding that at the same table. As we add data to the table, the database size increases (number of rows increases). But in horizontally scalable, we keep different boxes connected via Hadoop or Elastic MapReduce which will process the added data.**[00:30:20] – What does it take to hook up a DynamoDB instance to a Rails app?We could integrate DynamoDB by using the SDK provided by AWS. I provided steps which I’ve outlined in the blog - how to create different kinds of tables, how to create those indexes, how to create the throughput, etc. We could configure AWS SDK, add the required credential, then we could create different kinds of tables.[00:33:00] – In terms of scaling, what is the limit for something like PostgreSQL or MySQL, versus DynamoDB?**There’s no scalability limit in DynamoDB, or any other NoSQL solutions.
- CorgUI Jason Swett
- Database Design for Mere Mortals Charles Maxwood
- VMWare Workstation
- Ruby Rogues Parley
- Ruby Dev Summit Chandan Jhunjhunwal
- Twitter @ChandanJ
RR 314 DynamoDB on Rails with Chandan Jhunjhunwal
DAVID: I remember back in my early days of development, I was storing images in the database. That was a fun trip. That was back before I knew that, no, never ever do that. [Music][This episode is sponsored by hired.com. Are you searching for a new job? That could be stressful, scary and time consuming. Plus your recruiters try to sell you on roles you don’t actually want. And the job feels like you’re throwing your resume into a blackhole, never to be seen again. And sometimes, you go all the way through the interview process just to find out at the very end, that the salary offer or the company culture doesn’t match what you’re looking for. Hired is the world’s most intelligent, talent-matching platform for full time and contract opportunities in engineering, development, design, product management, data science, sales and marketing. We make your job search faster, focused and stress free. Instead of endlessly applying to companies and hoping for the best. Hired puts you in control on when and how you connect would compelling new opportunities. After completing one simple application, we help employers apply to hire you. And when hiring you, you receive personal interview request and up front salary information so you could make informed decisions about what opportunities to pursue over a condensed timeline. Hired offers access to more than 4000 innovative employers including big brand names like Facebook and smaller emerging startups. The size and type of company you want to connect with is totally up to you. And we help you find new opportunities in 17 major cities in North America, Europe, Asia and Australia. Hoping for a relocation? Let them know! Your privacy and autonomy in your job search is of utmost importance and if you go check them out at the show’s link. That’s hired.com/rubyrogues. You can get double the normal hiring bonus that they offer. That’s $600, instead of $300. So go check them out at hired.com/rubyrogues.] CHARLES: Hey, everybody and welcome to another Ruby Rogues podcast. This week on our panel, we have Jason Swett JASON: Hello. CHARLES: David Kimura DAVID: How’s it going? CHARLES: I’m Charles Max Wood from Devchat.tv. A quick shout-out, I have rebooted Ruby Rogues Parley into a Slack channel. So if you’re interested in that, come check it out. We also have a special guest this week and that’s Chandan. And I’m not even going to try and say your last name. CHANDAN: Hello, Chandan Jhanjhanwal. My last name is fine. CHARLES: Awesome. So do you want to give a brief introduction to who you are, what you’re about? CHANDAN: Sure. I’m an owner of Faodail Technology, which is currently helping many start ups for their web and mobile applications. We started from IBM and we do designing and building scalable mobile and web applications. I started my career back when I was working with IBM, where I mainly worked on C++ and DB2. And then, web development and mobile development, I was pretty much interested in it and I started. I joined three companies, which I was worked primarily on Ruby on Rails. Since then, since the last 4.5 years, I’ve been working primarily on Ruby on Rails. I started with … Rails was 3.1.8. After that, I’ve pretty much used all the Ruby on Rails versions. I have developed many applications like in education domain, or finance, healthcare. And in my previous company, I was working at a… So during couple of applications, that’s where I found that some client wanted something that’s pretty much scalable. That’s where I lined it up with different technology and I started working on DynamoDB on Rails. CHARLES: Nice. And I ran across your article on how to set up DynamoDB on Rails. I think I found it on Reddit. And I’m wondering because I don’t know how many Rails developers or Ruby developers are super familiar with DynamoDB. So do you kind of want to give us the ten thousand foot view on what it is and how it works? I know that it’s NoSQL but I don’t know if people know much more beyond that. CHANDAN: I would say that majority of developers work in PostgreSQL, MySQL or other relational database. The reason is it provides relational database model. Ruby on Rails is picked up by many startup or founder for actually implementing their ideas and bringing them to scalable products. So if you talked about AirBNB or Twitter, they only started with the Ruby on Rails. And they started with some RDBMS like MySQL but there’s a point where you actually want to scale your application. Scaling of AirBNB and Twitter works, they certainly need to work something like NoSQL database. I would say more than 80% of developers, they’re mostly working on RDBMS databases. For the remaining 20%, their applications need many startup productivity and they want to capture large amounts of data, so that’s where they go with NoSQL. And in NoSQL, there are plenty of options like MongoDB, Cassandra, or DynamoDB. So the benefit with DynamoDB is that it’s kind of posted application provided by AWS. So if we go with MongoDB, in AWS, there’s no provided MongoDB. We can’t take this out of any third partition hosted MongoDB or we can install directly. And with Cassandra, it requires a lot of infrastructure setup and costing, and you’ll have to have a team which is kind of maintaining it on day to day basis. So DynamoDB takes all those pain out of your team and you no longer have to focus on managing the infrastructure. You use it as a service where you can scale directly via a direct linking, or there’s a dashboard where you can simply edit some configuration. You can create their tables. From their dashboard, you can scale depending like how many capacities you need. So all in all, I can say that apart from scalability and all other stuff, it takes a lot of burden from the development team to host a service, which is pretty much why, actually, for a couple of last projects, I have created DynamoDB instead of going with Mongo or Cassandra or any other NoSQL databases. JASON: Chandan, I have a question. Let’s say you’re working on an app that you have reasonable expectation. It’s going to get big eventually and you’re going to have to scale it. Do you think it’s a good idea to start with a regular SQL database? And then, switch to NoSQL database when the situation calls for it? Or do you think it’s better to just start with the NoSQL database from day one? CHANDAN: I would say that it depends on a couple of factors. One thing is, certainly, for many of the applications, they start with RDBMS, mainly because of, I mean, they first want to get some access, and probably switch to something like NoSQL. It is recommended if you see that the incoming data and their capacity and you have decided that… when you have projected, at least, what will be the usage for the next six months over the year. The second thing is familiarity, most of the cases, if you go to a market, most of the developers are more familiar with RDBMS, SQL queries, the database. So in those cases, switching to NoSQL might cause you a falling out with a developer who can easily work with it. But at the same time, say, if you’re building some media application and then, you’re pretty much kind of anticipating based on, say, you have some prototype ready, and you experimented it, and you get to see that there’s a huge data coming in. For example, say, the feed application or say, messaging application, where you know that there will be a lot of chat happening. You can accommodate that in RDBMS but I would probably not recommend if you anticipate that, say, next 6 months you’re going to take a huge number of users. DAVID: So DynamoDB really geared towards a replacement for the RDBMS? Or can I also use it as a caching mechanism or cache store? CHANDAN: I would not say replacement, exactly, again it depends on the application and developers perspective. Like in all of my application, what I did was, I integrated both … main database but those segment where I could see that there’s a lot of activity happening, the database will keep growing at a very large piece. So there, I plugged in DynamoDB to ensure that those user activity’s access will be logged in DynamoDB with eventual consistency. And the remaining part of the application was handled by RDBMS, like user authentication, or different kinds of profile data, and all of the stuff. It’s not that you’ll have to use a replacement. You could, I would say, the better work is to… where you can see a clearer correlation. You’ll see that there’s a certain limit to that like number of users. We talked about Reddit. The number of users has increased exponentially but at the same time, the number of hosts increase, even at way higher rate. So probably, for user authentication or your user profile management, you could use RDBMS and for post management and all of the stuff, you might want to use DynamoDB. Having said that, eventually, you can use DynamoDB as a choice, and how you could then configure your database. But in many applications, what I’ve seen is that they have used a combination of them. Mainly because of the startup or the company is initially not pretty sure how the user increase but they were pretty sure about the kind of interaction the user will do. It may have like pretty huge interactions and the number of interactions will be like, at least, say, 100 or 1,000 times more than that for months. DAVID: That’s interesting. I could definitely say where that could be useful. If you have something like a paper trail log where you keep different versions of things, that database could grow exponentially as you’re number of users increase. Having something like that off-loaded to DynamoDB could definitely help your SQL performance. CHANDAN: Right. Other use cases would be like if you’re building a game. So if you’re like building a leaderboard or capturing, “Who’s on the top?” So there, as well, you could use these two databases. Other use case could be putting application where you have a lot of users working on something. There, you could easily use DynamoDB, which you could use the leverage of parties and all of the stuff that would increase scalability. You can easily scale quite a lot. But yes, the logging which you said as an example, basically, was a very good use case for this case. CHARLES: So then, is this something that you would want to use? It sounds like you might want to use them in tandem with an RDBMS? How do you decide if that’s a good fit or if you actually want to use this for all of the data in your system? CHANDAN: So then, I would say, we have discussed whether we should select DynamoDB or RDBMS. The place where we say that this application is going to be picked from day one is where the number of data which will be coming will increase. And also, it depends on the development team you have. So say, your team is pretty much familiar with DynamoDB, or any other NoSQL database, and they find it easier to design and query all of these stuff, that’s where they could use directly DynamoDB. But in many applications where you start with, say, a startup or mix-side business, I see that the combination of these two have worked. And also, the benefit is when you’ve started using two databases, you think in terms of micro services or service-oriented architecture. If we talk about Netflix, or Amazon, everyone uses it. So the benefit, really the one thing that you could use certain thing with RDBMS, certain thing you’ll use with NoSQL, if you feel that your application is like going to be a… A couple of situations I’ve seen, the clients wants handling two databases to go with one NoSQL database. CHARLES: Hey, one other thing that I’ve been trying to figure out. I just didn’t have enough time to really dig deeply into how DynamoDB works. Is this a document store or is it more like, Cassandra, or something else where you have sort of columns and… CHANDAN: You can say key value pairs or document store. It’s being used, mainly, if you want to go with Cassandra or DynamoDB. The terminologies are different, but having said that, you could actually implement same thing in Cassandra, in DynamoDB or even in RDBMS. You just have different terminologies and the way you design the database. Like in DynamoDB, you have something like hash key and range key, and the remaining data fits into… You cannot call it column, basically. But you can easily define the correlation between the two. DAVID: So what are some use of DynamoDB? Some of the gadgets that we may need to look out for? CHANDAN: Right. So DynamoDB, when we design the database of like different tables of DynamoDB, there are a couple of things, which we really need to consider. For example, it provides you a local secondary index or global secondary index. There are certain limitations. Like in RDBMS, when we’re designing tables, when we want to receive the data query pattern, we find indexes on top of that. So that the RDBMS or the database can decide how to query the table. But here, what we have is, we define local secondary index and the time of creation of the table. And once it’s created, it cannot be deleted. So once you clean the table, you cannot create local secondary index later. So if you need an index, you have to define a global secondary index. And also the size of the local secondary index could be lesser than 10GB at any point of time. Other thing which we need to take care of is the read and write capacity unit. Whether you want to define a table, essentially, this thing will play important role, mainly because you basically subscribe to these units from DynamoDB. Say, you needed a 1,000 read capacity unit per second, but somehow there was a user exceeding that, then, basically, it will result in exception. DynamoDB provides a five minute buffer for any unused capacity but for those kind of instances, you really need to gauge your users. How much do you exactly need? On the top of that, you would need something extra. But you cannot go limitless because it will cause you something. So the number of read capacity unit, write capacity unit, based on that, your expense will increase. The other thing is with local secondary index and global secondary index, you need to define the RCU and WCU. Whenever possible, one should always do batch write or batch read. Othewise, doing that sequentially will increase your network latency. One other thing which we have to keep in mind is the maximum item size, which Dynamo can handle is 400kB. So if you’re storing huge file and all of the stuff, what you might want to do is you might want to store them in some, say, S3. And you can add a pointer in your DynamoDB table. So that you don’t actually store that huge file inside your database because it uses data pointer to that. Basically, when we define our read capacity unit and write capacity unit, then, all of these stuff, you also define the parts. Say, today you need 100 read capacity unit and 100 write capacity unit but later you decided that you need 200. Then, the good thing about DynamoDB is it does everything in background. There is no unavailability or service unavailability. In the background, it will create other parties and then, as soon as it’s done, it will switch to the newly created parties. So essentially, you can save. The other good thing is it automatically replicates real time application. So you don’t have to really maintain that. In case of Cassandra, you would have to maintain all the replication logic, all the replication servers. At the same time, if you want to increase the capacity or throughput, then you may want to do that. DynamoDB facilitates this. Then, you don’t have to care about that. Other important thing is when we create a DynamoDB table, probably, you might want to ensure that it resides on the same location where your application resides. And to see the capacity, probably, one thing you could do is, you can install the downloaded development works of DynamoDB, and you need to have some metrics to gauge that. So that’s when I said, “It depends.” Many applications start with RDBMS, and then, when they see that there’s a certain number of throughput, which needs to increase in scale, that’s when we plug DynamoDB. Defining RCU, WCU is very critical, assuming that you do batch write and batch read. It will certainly be very beneficial. Selecting the right join is also very beneficial. And the 400kB is defining portioning. Local secondary index and global secondary index are equally important. DAVID: Yeah, I remember back in my early days of development. I was storing image in the database. That was a fun trip. That was back before I knew that no, never ever do that. JASON: I used to do that same thing, as well. People told me not to do it. And I did it, anyway, for a long time because I thought it actually made sense. And I think now that I was probably wrong. But I’m just curious on your take on that. This is a little bit of a tangent but why don’t we store images in the database? CHANDAN: I would say that there are better places to store them, which is faster, cheaper, and easily used in your database. Your query of the data and writing takes time. There are better storage like CDN or S3. But if you retrieve that from database, it essentially brings your application, in terms of performance, down. JASON: Yup. And that’s pretty much what I was told. And I think those are good reasons. And now, I don’t put the images in the database anymore. My reasoning back then, was that images are just data. And so, it makes sense to put them right in there. You could inform consistency more easily if you do it that way but I don’t think those were very good reasons. CHANDAN: A very good reason I could add here is, if you want to increase size, these days, there are multiple screen sizes. And say, you want to fetch a proper size of image based on the user devices screen. In that case, resizing and all of the stuff inside the database and doing them can be cumbersome. Again, you’ll repeat adding different columns and we will be storing those different sizes of images. So instead of going back to S3, or any other image storage on the cloud, is a good option because you could easily retrieve different files without affecting your database performance. DAVID: Now, that you mentioned that, you could sort of creating lots of deadlocks in your database. That’s never fun either. JASON: Here’s another question for you Chandan. So when I’m creating a new application, my default data store, and my go to data store is PostgreSQL. Some people like PostgreSQL. Some people like MySQL. Some people use other RDBMS’s. But I’m probably going to use something like that, I’m going to use some kind of RDBMS, as opposed to something like MongoDB as my go-to. Do you think that it’s kind of a way to go? Do you see it the same way that in RDBMS, your go-to default option, and only use a NoSQL database if the situation specifically calls for it? Or do you think there’s a potentially good reason for NoSQL database as your default go-to data store? CHANDAN: Data are too important in our API’s. First thing is, if you can clearly define the relationships between the data. If you have some data, which is completely unstructured, if you try to store back in RDBMS, it will be a pain. If we talk about blogging, and we talk about the kind of media which gets generated in our day to day life, if you try to model them in a relational database, it will be pretty painful and eventually there will be a time when you don’t know how to create correlations. So you will end up creating a spider web where things will be launched and performance decrease drastically. And the second thing I would say is the familiarity, many times I’ve seen developers who find very much comfortable with RDBMS. If you see their application, there’s no kind of those unrestricted data or don’t have that kind of scalability requirement from the beginning. And probably, you might want to start with RDBMS first and then later, when the need arises, you can integrate DynamoDB, or any other NoSQL database. JASON: Yeah, I think I would agree. And one thing that I hope that new developers understand is that NoSQL databases don’t exist because SQL databases are now obsolete. It’s something that’s complementary to RDBMS’s. And it’s something that’s a different use case. It’s not a replacement.[This episode is sponsored by compose.io. Compose is a fully managed database hosting with extra security scaling and performance. Posted on dedicated SSD servers, you can pick from highly available databases, MongoDB, Elasticsearch, Redis. Compose Enterprise comes with easy scaling, which you can add additional notes any time. It has auto-scaled resources like storage, memory and IOPS, RESTful API’s, central console to manage all your deployments, and premium support with guaranteed response time with priority ticketing. With Compose Enterprise, you can free up your time to focus on building your app instead of managing your database. Check them out at enterprise.compose.com. And if you try Compose, you get a free special edition t-shirt. Hurry, quantities are limited! That’s enterprise.compose.com.] CHANDAN: I would not say RDBMS is obsolete. In fact, many applications are still using RDBMS. In fact, Google and Twitter also uses MySQL until today. It’s just that the amount of data which is being generated is… say, 10 years back, we did not have that amount of data generated. So we were pretty much happy with RDBMS. But these days, apart from unstructured data, the amount or volume of the data, which is being generated on day to day basis… I missed to mention this. When you have a lot of data generated on day to day basis, if you go with RDBMS, you could do sorting or partitioning all the list. But eventually, there will be a point where it will fail because usually it’s vertically scalable. But if you talk about NoSQL, you can do it horizontally scalable, and you can deal with technology like MapReduce or Hadoop. JASON: Sorry, can you explain what you mean about the horizontally scalable versus vertically scalable? CHANDAN: We have a table and we keep adding. When someone posts, we keep adding that at the same table. As the number of rows increase, we have like millions of rows, and we need to add more. We just need to increase the database size or we could do something like sorting for certain index for partition 1, and then, partition 2. But when we talk about horizontally scaling, essentially, you can think of different ways of sorting. But the way it works is when we have horizontally scalable, we keep different boxes, which end up having a database of 1TB boxes connected via Hadoop or Elastic MapReduce. There are different solutions provided by AWS, Google and all the big companies. There, we can basically localize those things on those boxes, and query the data. And then, basically, write them accordingly. Basically, we can leverage these kinds of changes and make things horizontally scalable. If we talk about, Facebook’s terabyte of data, coming everyday, so if we try to store that in our database, in a single database, or single table, then they will have to keep increasing the sizes of the tables. In doing that, you could have something like small boxes and we could have something like Elastic MapReduce, or Hadoop, which will process them. CHARLES: So what does it take to actually hook up a DynamoDB instance to a Rails app? Because in your notes, you said that there isn’t really a mature solution for that, so you don’t have like Mongo or an active record-type for it. CHANDAN: So when I was researching, I could find the Dynamoid gem but there are certain limitations. For MongoDB, it’s kind of enough for developer who wants to integrate MongoDB in their applications. But as far as DynamoDB is concerned, the Dynamoid gem has couple of its use and a couple of limitations. Basically, we could integrate and essentially use the SDK provided by AWS. I’ve been using that, probably, we could have steps which I have outlined in the blog - how to create different kinds of tables, how to create those indexes, how to create the throughput and all of these stuff. Basically, I would recommend using AWS SDK. The way we could integrate using the AWS SDK is, we could configure it, and then, add the required credential. And then, we could create different kinds of tables. One thing we must ensure or we should pay attention to is we could not create any several clients for DynamoDB. Many developers - what we do is every time they have to interact with DynamoDB, they create a client and then they retrieve the required information. And if you don’t go back, the recommended way to do is creating DynamoDB client and then, basically, there should be one instance of the client’s application. And using this client, you could interact with all the tables. You’ do not end up creating multiple instances of something, which is redundant, which is also a good design pattern. DAVID: DynamoDB looks interesting. Now, I definitely can see some uses for it. It might be something I have to check out. CHARLES: I guess one thing that I did. See here, that I was kind of curious. You kept talking about scaling with this. Where do you find the limit for something like PostgreSQL or MySQL, versus something like DynamoDB? I mean, how big can you get? CHANDAN: With DynamoDB, I would say, almost there’s no limit because it also uses the Elastic MapReduce to process real time. There’s no scalability limit in DynamoDB, or any other NoSQL solutions. With RDBMS, I would say, there is one application where we had, almost, I would say more than hundred million… At that point of time, I could see that scanning through the table to retrieve the post of the user, there was a lot of time where the throughput was pretty bad, or essentially, the indexing was getting cumbersome. That’s where we could figure out whether we could load this to DynamoDB with appropriate partitioning, with respect to say, monthly or yearly. That was one point where we actually moved of the part of application from traditional RDBMS PostgreSQL to DynamoDB. CHARLES: One of the things that I wanted to bring up here that you had in your notes was, it’s a NoSQL database and a lot of these NoSQL databases implement eventual consistency. And this says it has support for eventual consistency and strong consistency. CHANDAN: Basically, when you call the API at that point in time, you could set a flag whether you want strong consistency or eventual consistency. And the thing is when you ask for a strong consistency, just takes a two capacity units so essentially, the benefit of eventual consistency is certainly you don't need the RCU or WCU. But at the same time, you are happy with a little bit delay. I mean, say, if you posted something that you are fine if it appears with others after say a few millisecond or a second. But there can be places like if you talk about ... So we do not want something to happen with eventual consistency as soon as your ... the others will be created. So that's where you need something... a strong consistency where the business cost for consistency basically overcomes the cost for the extra spending on the infrastructure. And there's one more thing I could add like the different... like the good, bad, and the ugly parts for the DynamoDB. Out of which, like the good part, I could say is hosted alias-enabled NoSQL database where you don't need to do any infrastructure setup. AWS SDK, which is provided by them, supports almost all the major programming language. And in Java, they also have like a built-in library image directly being directed with Java applications. You don't have to maintain ... create time replications which are automatically managed. And DynamoDB also provides like a DynamoDB streams where you code, process, and pipeline the dataflow. The bad part, I would say, is you really need to understand and go through the complete documentation. It has a good learning curve because, I would say, with great power ... comes with great responsibility. So, when you are designing things, you have to have a great understanding of what actually you are building, what exactly you are looking for in terms of scalability, read, write, etc. And you also have to keep in mind that there are few things which are like local secondary index which can be created only at the time of creation of table but later, you cannot change them. You cannot change the hash key or ... key once the table is already defined. And the other thing is the number of local secondary index of global secondary index you create, say you created five such indexes, whenever you write one time in the table, it is essentially gets written into those five indexes. So essentially you are inferring five time costs. So, you cannot simply go ahead. The kind of flexibility you have in RDBMS, you can create as... I mean as many indexes as you want. More than five indexes are never recommended. But you do not infer any additional cost. But ... associated cost and the ugly part, I would say, is if you browse the read/write ... of your application will just start ... exception. Now they are ways by which you put in ... that. But that might take a couple of second for which you replicate and you will remain unresponsive. And to define the WCU or RCU, you really need to have a good understanding of what exactly are we going to build and all the ... will show that you subscribed to the right amount, inserting that you do not infer to much cost at the same time, you don't let your application fall in the times of the spikes. CHARLES: Alright. Well, if there aren't any more questions about these, let's go ahead and head into some picks. [Dear, Ruby Developer. Are you sick and tired of working on crampy old legacy code bases? There's got to be a better way! If you want to get a better job, here's what you can do. Find a technology that's really in-demand, build a side project using that technology. And then use that side project as experience to get your next better job. I've done this myself several times it definitely works. What I think is a really good technology to learn right now is Angular. Angular is really in-demand right now and it is not going away anytime soon. I have a free guide to getting started with Angular and Rails at angularonrails.com/rr. Good luck and enjoy this episode of Ruby Rogues.] CHARLES: Dave, do you have some picks for us? DAVID: Yeah, I have one pick. It's called CorgUI and it can be found at corui.io. It's kind of like an admin dashboard or template for Bootstrap 4. I have been playing around with it on a new project and I've been really impressed with it. It's one of the more well-documented admin templates that I've found. It's free to use and it's just an overall very pleasing experience. So, a lot of the methods and ... followed the Bootstrap 4 layouts so it's not like coming in to a completely weird and different admin template that's confusing with all their internal ... So, it's just very intuitive and it's pretty. CHARLES: Nice. Jason, what are your picks? JASON: I got just one pick. It's a book called Database Design for Mere Mortals. I think I have actually mention it on the show before but it seems especially pertinent right now. I heard about it like ten years ago and I finally bought it. And it's pretty good. It was mostly review for me at this point but if you're relatively new to database design, it could be really really good. And there's also some really interesting like a historical stuff that was news to me also. So, I really like that one. CHARLES: Awesome. I'm going to jump in here with a couple of picks. One of them is something that I kind of been fiddling with for the last couple of days. And that is VMWare Workstation. I'm on Windows and I just picked it up and I've been setting up VM's to try out a couple of different things. One of them which looks really promising is called GoCD which is a continuous deployment, continuous integration system. It is written by ...bot. And, yeah, I think it looks really awesome. So, yeah, I just started setting up my pipeline on GoCD and I just fired it up on a VM since I don't really need to run it out on the cloud for anyone but me. I'm really digging it so, anyway, I'm going to pick both of those. And then the last thing is just a quick reminder about Ruby Rouges Parley which is now a Slack channel so if you want to go jump-in, you can. My vision for this, if I can just take a couple of seconds to talk through it really quickly, is I want to kind of create a community around the show. We had that on the form for a while but the form kind of turned into a ghost town. But one thing that I would like to do in addition to that... So I have a keeping current channel in there right now. And so it posts from Reddit and Ruby Weekly and a few other places that I found on the web that provide good places for information. And then the other thing that I really want to do is I want to set things up so that we can start having experts out there from the community come in and speak to us on a regular basis. But in order to get some of the top people, you have to pay a speaking fee which is fine. I mean they're awesome so they're worth it. But paying that other pocket is a little bit tricky and so what I plan to do is I plan to take the money that's coming out of that and pay for the speakers. Yeah, so I'm hoping to do a call every month. I probably won't have one for the month of June but probably will for the month of July. I may do a couple of workshops in there during the month of June myself just so, you know, if people have an interest in a particular topic that I can help with, we can do that. But, yeah, so that's one thing that I'm looking at doing there. And then finally the last thing that I'm going to pick is Ruby Dev Summit. So, a few people have paid for tickets or ask me about Ruby Remote Conf which was supposed to be in a week or two but, you know, I had trouble lining up the speaker that I wanted. And so, I'm essentially postponing it and I'm going to do it more of a summit style and less of a conference style which means that we're going to do it over the course of seven or eight days, probably over the course of a week. And what we're going to do is we'll just have a few talks everyday and we'll have the speakers around to answer questions after the talks. And I'm hoping to aim for a little bit more of a demo thing and a little bit less of a conference talk thing. And that way you can actually see people doing interesting things so... Anyway, I'm really looking forward to it. And, yeah, so if you're interested in that, go over the RubyDevSummit.com and check it out. Chandan, do you have some picks for us? Just things you like, things you want to shout out about? CHANDAN: Yeah. So, it is interesting to know... You had your work on Ruby Dev Summit and a ... Actually, we are starting a Ruby tutorial session which will be like live so if you want, we can ... and collaborate and show that basically, this is what we are planning to give to Ruby Conf... so that the people can learn these things and all these stuff. So there was a session which we aired, like a couple of weeks back, on like a ... DynamoDB ... And so, let me know your thoughts. We can probably collaborate on that and basically provide a training or expert talks on different topics on Ruby and Rails. CHARLES: Oh, yeah. Absolutely. And Ruby Dev Summit, I should mention, is going to be free. I'm going to be selling all access passes which basically get you downloads on the videos and stuff. But if you want to just come and watch the talks/demo, and then participate on the Q&A, that will all be free. Well, if people want to follow you, Chandan or find out what you're working on, I know you're on Medium. Are there other places that people should go to see what you're doing? Or if they want to hire you for something like this? CHANDAN: Sure. I'm reachable on Twitter with chandanji(?). You can reach me on email@example.com and I'm active on Facebook, Twitter, Medium, and e-mail. Or you can reach me via website and I'm also active on different Slack channel so I'll just post those details via Note or Skype. CHARLES: Yep. Sounds great. And just for the people who heard your email address who aren't quite sure what that was. That's chandan@faodailtechnology? CHANDAN: Yeah. So, I'll just announce, firstname.lastname@example.org CHARLES: Okay. Yeah, it is just something that I know if they heard the name they wouldn’t necessarily know how to spell it out. Alright, we will go ahead and wrap this up. Thank you for coming. CHANDAN: Thank you, everyone. DAVID: Talk to you all later. CHARLES: We'll wrap it up. We'll catch you all next week. JASON: Bye, guys.[Bandwidth for this segment is provided by cachefly, the world's fastest CDN. To view your content fast with cachefly, visit cachefly.com to learn more.]