Telehealth Improves Patient and Clinical Experiences across Continuum of Care
4905
Of your peers have already read this article.
1:30 Minutes
The most insightful time you'll spend today!
According to a National Academy of Medicine discussion paper, social determinants of health (SDoH) account for upwards of 80% of a population’s health outcomes. Breaking this down further, 50% come just from socioeconomic and physical environment factors such as education, employment, income, family and social support, community safety, air and water quality, and access to housing and transit. SDoH determine access to and quality of healthcare, and are contributors to a system of disparate access to care.
We believe that to more efficiently provide comprehensive healthcare access to more people, providers will leverage technology to blend in-person and virtual modes of care delivery.
In this article, Amwell and Google Cloud examine five ways telehealth – as part of a provider’s overall care model – can help democratize access to healthcare. (graphic url)
Remove distance as a barrier to care
8.6 million Americans live more than 30 minutes from their nearest hospital. Long drives can deter patients from seeking care or maintaining routine visits. On the flip side, 92% of Americans nationwide have access to wired broadband in the home or through mobile broadband. Therefore, having a virtual visit just a click away can help remove barriers to care, like distance.
Eliminate the risk of unnecessary exposure
Virtual care means that patients don’t have to worry about potential exposure in transit, while sitting in waiting rooms, or from direct interactions during in-person health visits. This is particularly relevant when it comes to those with chronic diseases or underlying conditions. Telehealth provides patients who may be more susceptible to diseases with access to continuous healthcare without putting them at higher risk for developing more severe symptoms. Virtual visits can occur in the comfort –and safety– of patients’ homes.
Extend access to specialized care
55% of preventable hospitalization or mortality in rural settings is due to lack of access to specialty care. With telehealth, physical proximity to specialized services–typically in urban areas–can be reduced as a limiting factor. Virtual solutions grant everyone access to top specialists, regardless of location.
Save time and money
By augmenting in-person visits with telehealth applications, providers can benefit from greater efficiencies in scheduling, helping to improve their bottom line, and add more flexibility to their workday. Meanwhile, patients can spend less on travel and childcare, limit time taken off work, and save on other costs associated with in-person visits — for a savings of $35 to $690 per visit. In a survey by the COVID-19 Healthcare Coalition, 76% of the 2,000+ patients surveyed across the US responded that transportation was removed as a barrier, 65% reported they no longer had to take time off from work for an appointment, and 67 percent reporting lower costs than an in-person visit.
Combat physician shortage and fatigue
Research shows there will be a shortage of more than 100,000 doctors by 2030. In the midst of a physician shortage, telehealth can help improve care delivery and make it more efficient, ensuring more people can still have their healthcare needs addressed. Additionally, by integrating intelligence such as case triaging along with telehealth into a virtual care model, providers can help reduce clinician burnout.
Amwell and Google Cloud are partnering to deliver transformative telehealth solutions that will make it easier for more patients to receive care and improve patient and clinician experiences across the continuum of care. One example includes embedding real-time captioning and translation services powered by Google Cloud’s AI and NLP technologies within the Amwell platform to increase health access and understanding for more people.
As physicians, we are excited that the future of healthcare will continue to blend cloud technologies like EHR-integrated telehealth platforms, AI, healthcare-trained virtual agents along with in-person care to create an integrated hybrid care model that will improve patient outcomes and unburden providers, all while expanding access to broader patient populations.
To learn more, download the whitepaper “Healthcare’s Virtual Transformation,” written in conjunction with Becker’s Hospital Review.
1: “Social Determinants of Health 101 for Health Care: Five Plus Five,” National Academy of Medicine, October 2017
Multicloud Mindset: Thinking About Open Source and Security in a Multicloud World
2773
Of your peers have already read this article.
1:30 Minutes
The most insightful time you'll spend today!
There’s never been a better time to talk about multicloud, and the Google Cloud Multicloud Mindset series on Twitter Spaces was created to do just that! This series takes place once every two weeks and features live conversations with top experts about the latest multicloud topics. You can join the 15-minute Q&A to ask your top questions and listen to episodes later offline for up to 30 days after we chat.
If you happened to miss our last few episodes, we recommend checking out our introduction blog to the series for what you missed. Let’s dive into our latest episodes, discussing the impact of open source and novel security challenges in multicloud environments.
Episode #5: ‘The intersection of open source and multicloud’
Open source technology has been an integral part of computing since its earliest era, predating even the birth of technology hubs like Silicon Valley. Open source projects have been responsible for giving us some of the most popular software in the world, such as Mozilla Firefox and the operating system Linux.
In the fifth episode, we sat down with Mike Coleman, Cloud Developer Advocate at Google Cloud, and took a closer look into the history of open source technologies, the role they play in a multicloud world, and the developer perspective on using these technologies to do their work.
The concept of multicloud anchors on the ability to run workloads across clouds and being able to pick the providers that are best suited for specific parts of workloads. Adopting open source technologies and languages empower companies to use the tools they need, regardless of cloud provider, without the fear of getting locked into a specific provider.
“As you think about moving across different environments, whether that be cloud to cloud, or developer desktop to ultimate destination, whether that be your data center or the cloud. Open source software allows you to do that…and multicloud is just an extension of that. This idea that I need to run the same software wherever I go.” — Mike Coleman, Cloud Developer Advocate at Google Cloud
If you’ve ever wanted a developer’s take on the impact of multicloud and the influence of open source in software development and digital transformation trends, you’ll want to tune into this episode.
You can access the full conversation on Twitter Spaces.
Episode #6: ‘Novel challenges in security with multicloud’
In the sixth episode of the series, we chatted with Dr. Anton Chuvakin, Security Advisor at Office of the CISO at Google Cloud, about how security leaders and architects are shifting away from traditional security models, which are increasingly insufficient for multicloud environments.
As more organizations adopt multicloud approaches, the question of how to maintain security in these complex environments and the increasing burden on SecOps teams is top of mind. As Dr. Chuvakin noted, the challenges in the cloud facing more traditional teams range from types of telemetry and logs to volumes and lack of clarity on detection use cases. However, these issues intensify when extended to include multiple clouds, where learning how to do something on one provider may be completely different on another.
“If you end up multicloud, you need to know public cloud and how it works at a better level than you would if you’re going to a single provider. Just like if you’re trying to repair three cars, you need to first learn how to repair cars. You need to have more cloud knowledge to do multicloud, not less. You need to have more powerful superpowers in the public cloud computing area because you can’t just learn one provider and call it a day.” — Dr. Anton Chuvakin, Security Advisor at Office of the CISO at Google Cloud
During the discussion, he offered three tips for tackling multicloud security:
- Learn cloud more, not less if you’re going multicloud. Multicloud requires more cloud knowledge because you can’t learn a single provider and call it a day. You’ll need to understand the differences in order to be able to secure multiple cloud environments.
- Focus on learning cloud identity management and how it compares to your traditional identity management service functions. Start with identifying the differences and similarities in what you see in one cloud and then continue with other clouds you use.
- Explore where your threat areas change in cloud environments when you plan detection and response activities to understand if your detection is covered across clouds.
If your organization is embracing multicloud, this is a great episode to listen and learn more about cloud security, the primary considerations and challenges facing security teams, and some helpful best practices for thinking about security in multicloud environments.
We’ll be sharing the latest topics and episodes with you every month in this blog series. Until next time.
Dual Run: A Proven Solution for Secure Mainframe Modernization
956
Of your peers have already read this article.
4:30 Minutes
The most insightful time you'll spend today!
CIOs are again evaluating their mainframe investments, balancing rising operational costs and difficulty finding talent with the perceived costs and risks of moving critical applications to the cloud. Increased business agility, technical innovation, computing elasticity, customer insights, and a growing talent pool all encourage CIOs to migrate and modernize from “Big Iron” onto public cloud platforms.
Google Cloud recently announced Dual Run, a new mainframe modernization solution, to help customers mitigate the risk involved in mainframe migrations and accelerate their migration to the cloud. Leaders can leverage Dual Run in their quest to ensure their mainframe modernization projects will succeed and pay off so let’s dive a little deeper into what Dual Run is, how it works, and how it can help you.
Mainframe modernization with a proven technology
Since so many businesses still run mainframes, we decided to partner with Banco Santander—one of the largest banks in the world—to bring Dual Run to our enterprise customers, since they had already built a solution. In fact, Dual Run was built on top of Banco Santander’s unique technology which has already demonstrated proven results in the regulated financial services industry. Now that Dual Run is available, Banco Santander has been using it to bring their data and workloads onto Google Cloud’s trusted infrastructure.
The concept is not new, but the solution is unique
Dual Run enables you to run a parallel production system, allowing you to simultaneously run workloads on your mainframes and on Google Cloud. While many enterprises running mainframes have thought about parallel production concept and a few even tried before, Google Cloud is unique among the hyperscalers to provide such a solution as an offering to its customers.
With a parallel production run, you can perform real-time testing of your applications on Google Cloud and quickly gather data on performance and stability with no disruption to your business. Once you’re satisfied with the functional and performance equivalence of the two systems, you can make the new Google Cloud environment your system of record, while existing mainframe systems can be used as a backup or decommissioned.
In addition to the transformative benefits you get from moving to Google Cloud–such as AI-based scalability, speed, and security–migrating mainframes with Dual Run offers you even more benefits:
Mitigate migration risk: Dual Run reduces risk during the migration by running your business critical systems in parallel with powerful reporting to track the difference between your current and target systems. This ensures there is no impact or risk to your existing mainframes while migrating to Google Cloud.
Secure migration investments: Avoid costly migration mistakes by basing your decisions and actions on empirical data acquired from your production system.
Reduce business testing effort: Compare the functional equivalence of outcomes in the current and target system with production data and drastically reduce the testing cycles of your migrated workload.
Accelerate migration: Speed up the entire mainframe migration process with a well-defined framework, automation components, predefined dashboards, and a tested approach. Empirical reporting available in Dual Run also enables customers in regulated industries to more readily respond to regulator reviews and requests for information.
Your migration journey with Dual Run
Dual Run is packaged with several automation components to aid your migration journey, from assessment all the way through to production.
This chart shows how Dual Run plays a key role throughout your mainframe modernization journey:
Let’s explore this illustration in a bit more detail, phase by phase:
Current state: This is your starting point, when your production workloads are still running in your mainframe. Dual Run helps you assess your mainframe workload for compatibility on Google Cloud.
After this assessment, Dual Run’s conversion engine helps address the incompatibilities in your current application and then migrates the application and data to Google Cloud. At this stage, you have your current application executing on the mainframe and your migrated application is ready to be executed or tested on Google Cloud.
Dual Run state: In this state, the migrated workload will be executed in two stages.
Dual Run stage 1:
In the first stage of Dual Run, your mainframe will remain as the “primary” system — meaning the response and outputs to other systems are sent from your mainframe — while the migrated workload will be executed in parallel in Google Cloud as “secondary.”
Dual Run performs the following actions as a cyclical process, repeated until you reach your desired migrated application quality is achieved:
- All workloads — batch & transactions — executed in the mainframe are replicated in Google Cloud
- The outcomes from both systems are validated to report any differences, enabling you to take corrective actions in migrated applications
- The functional and performance differences between the two systems will be observed, and the mainframe and Google Cloud data are periodically synchronized to bring both the systems in sync
Typically, most of your migration time will be spent in the first stage of Dual Run until you are satisfied with the results. The key goal for this stage is that your primary, business-critical mainframe workload is not disturbed while your migrated application is tuned to provide the exact same results as your current application.
Dual Run stage 2:
When the Dual Run reporting and results confirm that the migrated application matches your mainframe system, Google Cloud then becomes the “primary” system, while your mainframe will still be executed in parallel as “secondary.” Dual Run will enable you to do a smooth switch between primary and secondary systems through a configuration management system.
Target state: In this final state, the mainframe can be decommissioned while the Dual Run components are removed, enabling an optimal and efficient business execution with Google Cloud.
Summary
For any business or organization that has to migrate or modernize their mainframes, Dual Run offers a unique solution to achieve this with reduced risk and time. In fact, what we’re seeing from our customers is that Dual Run offers the right combination of proven experience, engineering, and strategic partnership that is essential for mainframe migration success. If you would like to learn more, check out our mainframe modernization website.
Google Cloud Migration Speeds Up The New York Times’ Journey to New Normal
5795
Of your peers have already read this article.
2:30 Minutes
The most insightful time you'll spend today!
Like virtually every business across the globe, The New York Times had to quickly adapt to the challenges of the coronavirus pandemic last year. Fortunately, our data system with Google Cloud positioned us to perform quickly and efficiently in the new normal.
How we use data
We have an end-to-end type of data platform; on one side we work very closely with our product teams to collect the right level of data that they’re interested in, such as which articles people are reading, and how long they’re staying onsite. We frequently measure our audience to understand our user segments, and how they come onsite or use our apps. We then provide that data to analysts for end-to-end analytics.
On the other side, the newsroom is also focused on audience, and we build tools to help them understand how Google Search or different social promotions play a role in a person’s decision to read The New York Times, and also to get a better sense of their behavior on our pages. With this data, the newsroom can make decisions about information that should be displayed on our homepage or in push notifications.
Ultimately, we’re interested in behavioral analytics—how people engage with our site and our apps. We want to understand different behavioral patterns, and which factors or features will encourage users to register and subscribe with us.
We also use data to create or curate preferences around personalization, to ensure we’re delivering to our users fresh content, or content that they may not have normally read. Likewise, our data also gets used in our targeting system, so that we can send out the right messaging about our various subscription packages to the right users.
Choosing to migrate to Google Cloud
When I came to The New York Times over five years ago, our data architecture was not working for us. Our infrastructure was gathering data that proved harder for analysts to crunch on a daily basis. We were also hitting hang ups with how that data was streaming into our system and environment. Back then we’d run a query and then go grab some coffee, hoping that the query would finish or give us the right data by the time we came back to our desks. Sometimes it would, sometimes it wouldn’t.
We realized that Hadoop was definitely not going to be the on-premises solution for us, and that’s when we started talking with the Google Cloud team. We began our digital transformation with a migration to BigQuery, their fully managed, serverless database warehouse. We were under a pretty aggressive migration timeline, focusing first on moving over analytics. We made sure our analysts got a top-of-the-line system that treated them the way that they themselves would want to treat the data.
One significant prominent requirement in our data architecture choice was to enable analysts to be able to work as quickly as they needed to provide high-quality deliverables for their business partners. For our analysts, the transition to BigQuery was night and day. I still remember when my manager ran his very first query on BigQuery and was ready to go grab his coffee, but the query finished by the time he got up from his chair. Our analysts talk about that to this day.
While we were doing the BigQuery transition, we did have concerns about our other systems not scaling correctly. Two years ago, we weren’t sure we’d be able to scale up to the audience we expected on that election day. We were able to band-aid a solution back then, but we knew we only had two more years to figure out a real, dependable solution.
During that time, we moved our streaming pipeline over to Google Cloud, primarily using App Engine, which has been a flexible environment that enabled quick scaling changes and requirements as needed. Dataflow and Pub/Sub also played significant roles in managing the data. In Q4 of 2020 we had our most significant traffic ever recorded, at 273 million global readers, and four straight days of the highest traffic we’ve had compared to other election weeks. We were proud to see that there was no data loss.
A couple of years ago, on our legacy system, I was up until three in the morning one night trying to keep data running for their needs. This year, for election night, I relaxed and ate a pint of ice cream because I was able to more easily manage our data environment, allowing us to set and meet higher expectations for data ingestion, analysis and insight among our partners in the newsroom.
How COVID-19 changed our 2020 roadmap
The coronavirus pandemic definitely wasn’t on my team’s roadmap for 2020, and it’s important to mention here that The New York Times is not fundamentally a data company. Our job is to get the news out to our users every single day in paper, on apps, and onsite. Our newsroom didn’t expect the need to build out a giant coronavirus database that would enrich the news they share every day.
Our newsroom moves quickly, and our engineers have built one of the most comprehensive datasets on COVID-19 in the U.S. With Google, The New York Times decided to make our data publicly available on BigQuery Google’s COVID-19 public dataset. Check out this webinar for more details on our evolution architecture:https://www.youtube.com/embed/mtNlrFpschU?enablejsapi=1&
Flexible approach
We have many different teams that work within Google Cloud, and they’ve been able to pick from the range of available services and tailor project requirements keeping those tools available in mind.
One challenge we think about with the data platform at The New York Times is determining the priorities of what we build. Our ability to engage with product teams at Google though the Data Analytics Customer Council allows us to see into the BigQuery roadmap, or the data analytics roadmap, and plays a significant role in determining where we focus our own development. For example, we’ve built tools like our Data Reporting API, which reads data directly from BigQuery, in order to take advantage of tools like BigQuery BI Engine. This approach encourages our analysts to be better managers of their domains around dimensions and metrics, but not have to focus on building caching mechanisms of their data. Getting that kind of clarity helps us plan how to build The New York Times in the new normal and beyond.
If you are interested to learn more about the data teams at the New York Times, take a look at our open tech roles here and you’ll find many interesting articles at NYT data blog.
4102
Of your peers have already watched this video.
10:00 Minutes
The most insightful time you'll spend today!
HSBC Looks to Google Cloud to Transform Banking
HSBC, a global bank that is a central part of global commerce with a presence in 67 countries, serving 38 million customers ranging from individuals to small businesses to corporations and governments, and having over $2.5 trillion assets in its balance sheet, had a vision of being a cloud first company and wanted to transform the banking experience for its customers.
The bank wanted to glean valuable insights from its huge data asset of about 100 petabytes and wanted to use those insights to manage its business better. What it needed was a managed service with elastic capability so that HSBC can focus on the data science and management, which enables better customer experience.
For many years HSBC had, like most large corporations, tried to build its own data centers, provision the infrastructure, and run it. However, to realize its ambition of focussing on customer experience, the bank decided to partner with Google Cloud.
However, the journey wasn’t an easy one. Being a globally systemically important financial institution, it had to convince regulators across the world that moving customer data to the cloud is a good thing. Towards that end, it formed a joint team to work through all the challenges and created a cloud framework for banking describing the controls needed.
The results have been quite stunning. Able to calculate the global liquidity for a country in minutes rather than hours, run better financial crime analytics with speeds that are 10 times faster with a higher level of precision and accuracy have been some of the benefits that the bank has derived.
See how HSBC and Google Cloud are bringing a new level of security, compliance and governance capabilities to one of the world’s leading banking institutions.
Google Introduces BigQuery Connector for SAP to Power Customers’ Data Analytics Strategy
5471
Of your peers have already read this article.
2:00 Minutes
The most insightful time you'll spend today!
Google Cloud has a genuine passion for solving technology problems that make a difference for our customers. With the release of our BigQuery Connector for SAP, we’re taking a another big step towards solving a major challenge for SAP customers with a quick, easy, and inexpensive way to integrate SAP data with BigQuery, our serverless, highly scalable, and cost-effective multi cloud data warehouse designed for business agility.
Solving for simplified data integration
Like most businesses today, SAP customers are eager to unlock the immediate insights and opportunities within their ever-growing stores of business data. However, many are discovering just how hard it can be to take the first step in any modern, cloud-enabled data analytics strategy: combining SAP data with other cloud-native, and enterprise data sets in real-time and at scale. According to a 2020 SAPInsider study, more than half of SAP customers surveyed said data integration was their top analytics pain point. These companies urgently need a rapid, sustainable, cost-effective and scalable way to integrate SAP data with modern cloud data analytics solutions.
The BigQuery Connector for SAP gives our customers a solution: a fast, simple, cost-effective and massively scalable way to make SAP data fully accessible within BigQuery by leveraging customers’ existing SAP Landscape Transformation Replication Server (SLT) tooling and skill sets. It’s the first SAP SLT direct near real-time connector for BigQuery without the need to set up additional infrastructure or third-party middleware, and can be deployed using a variety of embedded or stand-alone deployment options. In fact, most customers can install the BigQuery Connector for SAP in less than an hour—a remarkably easy way to start working with our industry-leading analytics solution that delivers proven and quantifiable business advantages for customers. Additionally, the BigQuery Connector for SAP is not restricted to customers who have deployed their SAP applications on Google Cloud. Customer’s who are running their SAP applications on-premise, or on any cloud, can also deploy and realize the analytical benefits of the solution.
Designing a solution with customer requirements and investments in mind
When the Google Cloud team started work on an analytics data integration tool for our SAP customers, we began with a set of requirements designed to root out the usual sources of cost and complexity. These included:
- The need for real-time performance with deltas replicated in milliseconds
- The ability to integrate data from almost any SAP Netweaver based application running today, regardless of its deployment location (on premises, any cloud, Google Cloud)
- Automatic BigQuery data type mapping with minimal transformation required
- Generation of target tables in BigQuery directly from source, if required
- Application layer integration that avoids the issues of direct database access
- Leveraging customers’ existing SAP skillsets, change data capture, and infrastructure
An important step towards meeting these requirements came when Alphabet, Google’s parent company, decided to leverage SAP SLT as a foundation for developing direct data replication between SAP and BigQuery for its internal corporate landscape. SLT as part of SAP’s strategic Business Technology Platform, supports real-time replication of data from SAP or third-party systems to SAP HANA, however, one of its limitations was direct integration with targets like BigQuery.
SAP SLT was a logical foundation for developing the connector for several reasons:
- It’s widely adopted among SAP customers who likely already leverage SLT for SAP analytics data integration
- It works with almost every non-SaaS SAP application environment running today
- It supports real-time replication performance at massive scale
It was an obvious choice for the Alphabet engineering team who saw immediate value from integrating SAP with BigQuery.
“The BigQuery Connector for SAP has enabled fast, low latency data replication for billions of records from 500+ tables of our most critical financial and supply chain data. Now in one cost-effective BigQuery data lake, this ERP data can be combined with other data sources for previously impossible real-time analytics and ML use cases. This allows us to drive much deeper strategic insights that support business and operational excellence, management and P&L reporting and more.”—Anil Nagalla, Sr. Engineering Director, Financial Systems, Google
SAP data integration with BigQuery enables new value
By leveraging SAP SLT, the BigQuery Connector for SAP can integrate real-time data streams from any SAP system—while also taking advantage of customers’ existing SAP investments and skillsets.
At the same time, the BigQuery Connector for SAP does a lot of heavy lifting on its own. For example, it automatically handles the complex, multi-step process of transforming SAP data types for use in BigQuery—mapping data-type transitions between the SAP and BigQuery environments, creating a target table schema on BigQuery for the transformed data types, building the target BigQuery table, and even adapting as new data types appear in your SAP environment.
For teams that want to fine-tune the BigQuery Connector for SAP’s automated recommendations, the connector supports additional levels of customization and choice. But if you simply want to get the job done and give your data analytics team greater support for their high-value work, then you’ll love just how quickly and easily the BigQuery Connector for SAP turns the complicated work of data integration and performance to process large volumes of data into a done deal. By integrating enterprise data sets in real time, customers can drive differentiated value and unlock new insights and actions that drive a competitive advantage.
The BigQuery Connector for SAP really shines as an enabling tool that transports and transforms your SAP data to power analytics solutions enabled by accelerators like the Google Cloud Cortex Framework: a comprehensive set of reference architectures, deployment accelerators, and integration services designed to give SAP customers a fast and seamless path to value with their data analytics investments. Simply put, the more SAP data you make available within Google Cloud, the easier it is to get meaningful—and often game-changing—insights from these solutions.
Learn more about the BigQuery Connector for SAP
Ready to get started with your own SAP data analytics strategy on Google Cloud? Install the Google Cloud BigQuery Connector for SAP, and discover a faster, simpler, more sustainable way to power your company’s data analytics strategy.
More Relevant Stories for Your Company
Groupe Dauphinoise Grows it Customer Base with G Suite and Google Cloud Platform
As a leading French agricultural cooperative, Groupe Dauphinoise places collaboration at the heart of its philosophy. Working with farmers in the Rhone-Alpes region, Groupe Dauphinoise takes on a diverse range of activities from agricultural production to research and development to running retail outlets. As its operations expanded and strained its
Expect 40 Percent Higher Price-performance than General Purpose VM with Google TAU VMs!
In November 2021, we announced the general availability of Tau VMs. Since then, Google Cloud’s Tau VMs with Google Kubernetes Engine (GKE) have unlocked value for many customers who are now using Tau VMs for their production workloads, such as: Ascend, who achieved over 125% higher performance; Nylas, who gained
Google Invests 1 Billion Euros on Germany to Support Growing Businesses
In September 2001, the first-ever German Google employee switched on their computer in Hamburg. Since then, we’ve grown to more than 2,500 employees in four offices across Germany. Berlin, Frankfurt, Hamburg and Munich have long been our home, and we continue to invest in the growth of the local economy.
How to Pick a Database that is Suitable for Your Application
Picking the right database for your application is not easy. The choice depends heavily on your use case—transactional processing, analytical processing, in-memory database, and so on—but it also depends on other factors. This post covers the different database options available within Google Cloud across relational (SQL) and non-relational (NoSQL) databases
