25:19 Video
Reduce SAP HANA TCO with SAP HANA NSE, Intel Optane, & Pure Storage
Pure Storage has partnered with Intel to integrate their new Optane SSD memory into our FlashArray solutions for SAP. Watch this session to learn more.
Click to View Transcript
Mm. Hello everybody and welcome to today's webinar. Today we've got some exciting guests we're gonna talk to from Intel S. A. P. And pure. We're going to talk about reducing the total cost of ownership of ana to start us out, we'll have meg Mcdonald from Intel followed by robert.
Well, well product manager from S. A. P. And then Ryan arsenal, R. S. A. P. Field solutions architect from pure storage will wrap it up in today's webinar. We're going to focus on three things. So some key learnings, first of all we're gonna talk about obtain SSD from Intel, their exciting new chip on the storage side. This time then we're going to talk about some
warm data tearing and Hannah and how S. A. P recommends you maximize the efficiency of your S. A. P. Hana database. And finally Ryan is going to talk about how we bring those two together from the storage layer to reduce that on a total cost of ownership. So with that I'm gonna turn it over to you meg to kick us off.
Thank you. Thanks brian. Welcome and thank you for your time today. I'm meg Mcdonald strategic account manager with Intel Corporation and until we create world changing technology that enriches the lives of every person on earth. Our strategy is to drive innovation forward and to become an even bigger part of our customers
success. That strategy is underpinned by continuous innovation to create leadership. Products, urgent focus to deliver on our commitments, fostering a culture of execution and living up to our purpose Intel obtained technology is just one example of our innovation efforts. Intel obtained persistent memory and SSD s are revolutionizing memory and storage.
Intel obtained S. S. D. S. Deliver unprecedented responsiveness and increased performance over traditional three D nand SSD s enabling large memory pools, fast cashing and fast storage that accelerates applications and reduces transaction costs for latency sensitive workloads. It's technology alliance partners like pure storage and S.
A. P. That helped bring the possibilities of this technology to life solving business challenges and bringing new innovative solutions to market. I'm delighted now to hand this over to rob well S. A. P. Hannah product manager with S. A. P. Thank you meg. So to start off with let's take a moment to
talk about the concepts of data tearing um what your what the purpose of it is what you're trying to accomplish. So the analogy we most commonly use when we're talking about data, Terrian is a hot warm cold analogy where hot data is all your data is mission critical but you're hot data is not just mission critical but it's the data using for
real time processing and real time analytics. So you want the highest performance possible and you're willing to pay the premium in terms of cost ownership to obtain that performance from it. This is typically where in memory hana data comes in, right is the hybrid transactional analytical processing combining O. L. T. P. And O.
Lap operations in the same database. Warm data is data that's a little less frequently accessed. It's still mission critical. Um But you don't need or or maybe you don't you can't afford to pay that that top premium in terms of hardware to keep all that data in memory all the time.
All right. And then cold data is data that generally is older. It's less frequently accessed. This may be your audit data and maybe compliance data and maybe you know older sales records there more than a couple of years old where you still wanna be able to go back and look at them, you still need them accessible. They're no longer changed.
Being changed at least not not any on any regular schedule. Um And you're not querying them very often if at all. So if we Look at those three sort of very broad tiers for data storage, then we can look at what the appropriate storage architecture, what the appropriate database architecture is to to use for each of those tiers.
So we go to the next slide then we can start talking about what haunted native storage extension is. You start at the top, you look at the picture on the top right there. What we're showing there is a traditional hana pure in memory system. So with Hannah, the expectation is that all data is in memory all the time and that's the
the orange block with the hot data representing that that in memory. Data. Right. In addition to the in memory data, you also need memory available for working space. This is where you're actually executing the queries, building intermediate results that's generating the final final results to report back to the client.
So with hana the traditional or sort of default sizing guidance Is to have up to 50% of your memory volume available for data And the other 50% available as working memory. Alright. That can vary depending on your use case. That's that's kind of the default guidance. What's also shown in that picture is the persistence layer.
So even though he is an in memory database, we still need to persist the data to disk for recovery ability. Um for storage, you know, long term storage across restarts and so on. Right now. What that meant architecturally for haunt in terms of moving data back and forth to disk. Is that since data, since data was going to be in memory all the time?
We could load entire tables, columns or partitions as a single monolithic operation. Right. It was gonna be done once. Um We do have to merge results out to disk or persist data out to disk but we can do that lazily in the background. It doesn't affect your your transactions at the point of the transaction.
Now that's a very high performance architecture, very, very capable database but as these haunted systems grow as the applications using them age. Not in terms of becoming irrelevant but in terms of having been around for long enough that you're you now have data that is 345, 10 years old. All right. It isn't necessary.
You know, it can be harder and harder to justify keeping all of that data in memory all the time. You don't need it for performance reasons, but you still need it for record keeping for audit logs for um regulatory requirements. So one option would just be to offload that older data to an archive system. That adds a lot of complexity to your database
architecture, a much more a much simpler architecture um and a higher performing architecture overall is to keep that data in hana. But use the capability we introduced first in hana. S. P hana to S. P. 04 called native storage extension. And what native storage extension does is it adds a disk paging capability to haunt them.
This is an approach that traditional disk based databases have used forever. So whether you're talking about an S A P a S c, an oracle and Microsoft is data is primarily on desk and rather than having this memory space, it's twice as large as your data volume. Traditionally you would have a memory cache that was 10-20% of your data volume. Right? And then you would move data back and forth to
disk from disk into the cache as needed. Right? So native storage extension adds this capability to haunt them. It has a couple changes and imposes a couple of changes on hana. There. Number one is now instead of storing and
reading page global data. This data that's stored with native storage extension Instead of storing that as monolithic blocks that our entire column of up to as much as two billion records. Now we're storing we're breaking down those columns, those tables, those partitions into units that are arbitrarily called pages where paige is going
to have one or more value one more record on. It depends on the structure in order to read a single record. Then Out of a two billion record partition with native storage extension. I don't have to load that entire two billion records into memory. I can load individual pages and that's what we're showing in the bottom right picture where we've added something,
we've labeled the buffer cache. This is where pages are being stored in memory when we're working with them. Note that we're still persisting data to disk but now we have more active movement of data back and forth between memory and disk. All right. What keeps us simpler than other architectures?
Is that this is an integrated part of the core hana engine. The index server process. It also is a single physical persistence layer on desk. So compared to our older data, terrian technologies like high dynamic tearing where we had a separate physical storage on disk.
The persistence layer with Nse is the same persistence layer is used for in memory data. That means that all the core haunted features, like all of the backup recovery features, all the system replication features automatically work with nsC because they're dealing with that single haunted persistence layer. From our perspective, it also means that I'm managing a single physical database.
I haven't introduced any separate database. So moving onto the next line then just want to highlight a few more technical points, deeper technical points about how haunted manages data. So the first thing to look at here is the right optimized delta store just underneath the column store heading there.
The way hana manages insert update to lead operations efficiently for a columnar database is by executing those through this delta store. There is a single delta store for hana regardless of whether the data is in memory column notable data in the main store or whether its page laudable nsc based data being managed through the buffer cache. So all insert update,
delete operations are performed through the delta store and then merged into in the background and persisted to disk. Mhm Second point again is just highlighting that unified persistence layer where you're seeing both column mutable data in orange and page little data in yellow bean uh stored in the same physical files on disk.
Third point on this one is that the safe point operations. It's a single safe point operation. This is the point where we write out those changes to disk. So the safe point, which is a background operation takes care of all changes to both. Column notable and page global data at the same time.
And then a note on the buffer cache itself is how do we manage moving data back and forth between disk and memory? If we're only keeping some of that data in memory at any one time, what happens if we need more space than the buffer catch has? And again, this is a very well developed. This paging capability,
buffering capability has been around for decades. It's what databases have always traditionally done. And the basic algorithm used is a least recently used algorithm. All right. So when a page gets read into the buffer cache, uh we keep track of when it was last touched, as long as we have more space in the buffer
cache, we'll keep everything. They're just reading more pages as needed. When the buffer cache is full and we need to make more room, then we look at which pages are the stay list. Right. Which page has been the longest that I've since I last touched it last used it in a query. And those are the pages that will be ejected from the buffer cache to free up space for
additional pages to be brought in. So we went on to the next line. Um just a little bit about how this works. Alright. So if you look at the syntax on the right, you'll see that we the page legible Klaus shows up in a different position depending on what I'm trying to do.
So I can designate data to be page laudable to be stored using nsc at a table partition or column level. So the first example there were creating a column table has two columns. You'll see the page global clause is outside the end of the column. Call him definition list. All right.
So that entire table is being designated to be paged notable. So stored primarily on disk pages loaded into memory in the buffer cache as needed. The second example you'll see that the page global clause is after the first partition definition. So the partition range partition for values that are zero to less than 10 is being designated to be page notable.
So start primarily on disk whereas the catch all others partition is being kept entirely in memory and column literal. The third example then is showing an example where column two see to explicitly is being made page laudable While column one is being kept in memory. Alright, so the page laudable clause there you'll see is inside the brackets with the
column definitions. This can be particularly useful when you have for example a large comment column on a table. You know, you probably have a like query somewhere where you can search based on comments but usually most of the time you're wear clause or predicate is going to be referring to other columns in the table.
So offloading a large comment calling to be paged notable can reduce your memory footprint significantly while maintaining query performance by keeping those columns that are, you know, key to filtering your queries in memory. And then finally the the conversion between page laudable or column notable data, it can go either way.
Alright, so if I want to move an existing table calling partition to be page little, I can do that through an alter table. I can also move any of those objects back to be column notable again through an alter table. Final note here is in terms of what sort of partitioning we support, we support range, range, range partitioning, hash range and range hash partitioning
levels. So quite robust. Support for partitioning as to what can be designated to be paged notable. So final slide for me if you want to move on is just a few notes on sizing. So the picture on the right here is showing if you start from a two terabytes pure in memory hana system and you're looking to scale your haunted data volume up,
you can either do that by increasing the capacity of your hana system by adding memory which is the picture at the bottom left or for many customers who are working with a uh an appliance. Right. Where you have fixed resources, you can still scale your data volume significantly by carving out memory for the buffer cache and implementing nsc.
So Starting from the top, you see this was a two terabyte hana system in memory Ah that gave you nominally one terabyte of data volume. If you're working with an appliance bottom right, where you need to carve your buffer cash out of your existing memory, You can still scale comfortably to four terabytes of data volumes or four times increase.
If you're working in a hana cloud environment for example, uh where you have it's easier to scale your haunted capacity by adding more memory more compute to it Than rather than carving anything out of the existing space, you can add memory to it um and scale up easily 2-5 terabytes or beyond. So a few modes on sizing. Um First is that nsC as a
disk paging capability is not going to give you the same performance as pure in memory. Alright. So you do want to be aware of that If you're looking for the pure in memory performance, you want to keep your data entirely in memory of column notable. Uh The design goal for queries or operations using page little data Is for any individual operation to be no more than 2-10 times or to
take no more than 2-10 times as long to execute as a pure in memory operation Overall for customers doing a workload test. Typose see an overall impact of maybe 10%. Alright, so much better than that. And for individual queries typically see for expensive queries, results are closer to maybe a two times performance.
All right. But you know, you can't just move all of your haunted data into Tennessee and expect to get in memory haunted performance. So that's the first one. All right. Second. Is that the sizing of your buffer cache is critical to the performance of your your database with um with nsC when using nsC,
typical disk based database cache sizing would be again 10 to 20% of your data volume is available as cash. So our default guidance for customers starting an NsC implementation is to plan on a ratio of 181 to 8. Alright, so if you had four terabytes of page global data, They need want a buffer cache starting buffer cache of say 500 um and
then the final note here is just be aware of how haunted key figures the size of the buffer cache. So the configuration settings, the default configuration setting of the maximum buffer cache size in hana is 10% of hana memory which of course is a different number than 10% of the warm data volume. So it's really high level notes on sizing. Happy to cover more sizing questions and the
discussion later on. But with that I'm going to hand over to a Ryan arsenal from pure storage. Thank you. I appreciate it. That was that was really, really good stuff and I love how you hit on the performance aspects of nSC because I think that's really a good lead into what I'm going to talk about here
before I jump into that, just a quick overview of who is, who is pure storage for those of you who haven't heard of us, one of the fastest growing tech companies in the industry right now. Did you know, $1.68 billion in revenue last year with about 1500 new customers. And I think of the, the great start here is 48% of those were fortune 500 company companies.
Right? So starting to get some, some name placed in the market today. Um, we are in the top 1% of B two B companies when it comes to the net promoter score of 83.5. That's something that we really strive to keep within peer storage. Just for reference. The iphone today is around a 70 net promoter
score. People wait outside overnight to get their new iphone so you can see that, you know, people are talking about storage at the dinner table, which doesn't happen every day in the next slide brian, you know, the gardener report just came out for primary storage arrays and pure storage is a leader for seven years a row in a row. And I think we're really proud to say that
we're not only the, the leader in primary storage Pride gardener, but you can see there's quite a bit of white space between us and the closest competitor which which you don't see often in the Gartner report. So even even Gardner sees us as a as a clear leader and in storage for for for all all of your primary race brian.
So how do we, I kind of pull this together. Right. So hana data tearing is is a, it's a it's a great way to be able to manage the size of your hana database, whether it be for growth or whether it be just trying to fit it into memory. Um, and I have here, you know what happens when my data becomes critical, critical again and rob hit that your data is always critical.
Right? It's it's your business is is that's why you probably don't want to talk about an archiving project because you immediately become the bad guy when you're leading an archiving project at an I. T. Shop. Right? Because you're, your business is now thinking that the data is going to go onto a piece of
tape and into a back closet of the data center. Never to be seen again. Um it's a bad word when it comes to the business. The native native storage extension is a great way to be able to take that. That less critical data. I won't say non critical less critical data to rob's point and being able to still use it in a hana database when when you need it.
Um, we've done a lot of testing on native storage extension here at pure right. We are an all flash very fast storage array. So, you know, this use case really lends great for us to be able to still get great performance out of your storage when you're querying the data that you that you have is page laudable. But now as an I. T shop, you're starting to become having to
manage what's critical and what's not right. Whenever you have something that you want to put in memory, you may need to take something out and now your business analysts or even your basis team becomes data architects. Right to be able to manage this data going in and out. And I think that's where intel and obtain comes in to really be able to help streamline this process. Right.
So peer storage direct memory cache is based on the obtained technology where we put that storage class memory directly into the storage device. Right. It's it's not going to be fast as the RAM but it's going to be faster than your traditional S S. D. S that we have in our storage layer. We've seen upwards of 90% read times compared to D RAM at at a fraction of the cost.
Right? Because now you're no longer needing to scale that database up from an infrastructure standpoint, you're able to cash your haunted database. We sell these in either three or six terabyte chunks cash, your haunted database directly onto the pier storage flash array. So when you need that data, it's going to be there at your fingertips at almost the same
performance that you get from a different perspective. So I think, you know, the the joining here of obtained from intel S A P s page laudable functionality with NSE and then peer storage as being the fast storage on the, on the back end is really a really good marriage right to be able to manage your database size while while still taking advantage of the functionality from S A P to to
to to run on a critical mission critical system excited brian. So just a little bit about the results of our testing, um, this is compared to a direct direct attack storage device. Right? So your direct attached storage, which which is probably this on the slowest and and probably the most difficult to manage.
Right. When you put that nsc on a pier storage device, you're looking at a 50% faster performance, right? Because of our just our capabilities of being built from the ground up as all flash using end to end M V M E protocols to be able to get access at that data, you're immediately gaining 50% performance when you add octane on top of that,
which is that third, that third row up the direct memory cache, That's when you're really seeing the benefit. Right, 90% performance versus diagram in memory Hannah at a pretty big cost savings right? Because now you're no longer needing that giant compute device to be able to put this database plus plus all the copies that you have in this database across your landscape.
It becomes a lot more easy to manage, it becomes easier to manage growth and you can start to get aggressive on how much data that you put in in N. S. C. As page laudable versus storing in in hunted and dee brown. So a lot of, a lot of great results here. We continue to test this out.
Um if you have any questions on, on how, how, how we did this testing or or how we, how we look to move forward with S. A. P. And intel on this, we're happy to answer that after the case. But I think that is probably all that I have here, brian just wanted to thank everybody for their time today. Um you know, this is a great story for pure and intel and ASAP really,
I've seen it start to take shape in the marketplace. I talked to a lot of customers every day who who are looking for things like this
SAP HANA’s data tiering solution, Native Storage Extension (NSE), supports S/4HANA and allows you to move up to 80% of HANA data into a warm data tier. Housing this data outside of in-memory HANA, generally reduces costs by a similar percentage!
But traditionally such savings also came with a stiff performance penalty when you bring that warm data back into HANA for processing. No More.
Pure Storage has partnered with Intel to integrate their new Optane SSD memory into our FlashArray solutions for SAP. Optane dramatically reduces the latency associated your data’s return trip to HANA. With Optane SSD, aka DirectMemory™ Cache from Pure Storage, your users will not notice any difference compared to leaving their entire dataset in-memory. But your IT budget will love you. Think of all you can do with the savings!
3 Key Questions:
- What is HANA NSE and how does it work?
- What is Intel Optane SSD for Storage?
- How does NSE & Optane reduce HANA Total Cost of Ownership?
Meet with an Expert
Let’s talk. Book a 1:1 meeting with one of our experts to discuss your specific needs.
Questions, Comments?
Have a question or comment about Pure products or certifications? We’re here to help.
Schedule a Demo
Schedule a live demo and see for yourself how Pure can help transform your data into powerful outcomes.
Call Sales: 800-976-6494
Media: pr@purestorage.com
Pure Storage, Inc.
2555 Augustine Dr.
Santa Clara, CA 95054
800-379-7873 (general info)