test 100

00:01
okay, we're going to get started now,
00:03
and pass it off 
00:04
to Victor and Rayees.
alright, thanks for the intro Emily. 
so this is Victor Lee and with me is my partner, Rayees Pasha, and we're here today to talk to you about why tigergraph is much faster than a competition from an architectural standpoint. want to give you some insight into the architecture. i'm the
00:29
i'm the head of product strategy and developer relations at tigergraph, 
and Rayees works with me as a principal product manager focusing on the data base core.
we just have a few reminders for you about the webinar;
00:44
we're using zoom,
all your audio is muted, but you can ask questions using the QnA tab in your zoom menu. There 's a chat menu and a QnA tab, and we prefer that you use a questions regarding the content that you would like we- the presenters, to
01:03
answer in the QnA tab. you know, if you want to share something with everybody, that you need to for some reason; you could use- that's what the chat would be good for; or if you're having a technical issue. So the webinar is being recorded,
01:18
so you'll get a link to the webinar recording, and we're also going to send you a copy of the slides.
so again if you are having any zoom issues contact us through chat.
you can see both the QnA and the chat buttons at the bottom.
01:34
and with that i'm going to let Rayees get started into the material, because we've got a lot to say today .
01:42
thank you Victor for the introductions; hello everyone, first i want to thank all attendees for your interest in learning about tigergraph architecture,
and how tigergraph can help you with your graph analytics solution development.
i'd like to start the webinar with an outline of today's presentation:
02:02
first we would like to start with the system architecture overview- to give you an understanding of the overall tigergraph design and the key features.
.
02:12
next we'll dig deeper into the key aspects of how the data interacts with the system. so we tried to structure the presentation in a way where how the data gets ingested and stored inside the tigergraph system. and how the data is processed,
02:27
and then eventually how the data is retrieved by the user.
and then finally we're going to present details on the non-functional features which are very critical
02:37
for enterprises, for enterprise adoption, and these are the things like: high availability, transaction management, and security. i will go give you a more in depth- in design- of these key features.
02:54
as Victor mentioned, we'll answer all your questions- if you have any- at the end, you have time permitting, and also on the chat window, please log your questions.
so starting off with the system architecture- if you look,
03:11
 as the title suggests, we maybe a bit provocatively take- in tigergraph performance- great pride in its performance. and if you review our performance benchmarking data, for a lot of the industry standard workloads,
03:25
tigergraph is clearly ahead of the competition and in fact in some parts of those industry workloads don't even complete on other systems. and there's a reason for that- there's reason because a lot of the systems are not designed to scale to the level of data volumes and concurrency that's expected.
^%$#
03:45
 now the secret sauce so to speak behind this is not just one feature or one thing.
it's the overall architecture- the entire architecture which is a fresh implementation built ground up.
^%$#
03:57
and other brand new system that was developed.
and all the elements required to support that sort of scale were incorporated from the getgo- from the very beginning, natively.
so basically i want to start there, with the first architecture overview, to see where does the power comes from.
04:19
so let's start with some key features: like three- more than a feature is the feature areas. the three areas that i want to emphasize: our Real-Time-Deep-Link-Querying, how we handle massive data and how we enable in database analytics. let's start one by one
04:37
first if you look at Real-Time-Deep-Link-Querying, what does it mean? it means ability to perform analysis on deeply connected data. because if you think about the use cases that you have,
04:50
these are typically we're dealing with the really connected data. where analysis can lead to connected data- multiple hops from five to ten hops.
05:01
and that's pretty much the key reason why folks use graph database, because when they want to get the hidden connections, patterns, in the data.
they need a system that can easily travel data into five or ten hops without performance issues.
05:20
and that's what we delivered with this Real-Time-Deep-Link-Querying and the reason it's possible is because of our native graph design. 
we are not a bolt on engine, where graph- the storage implementation is different from the engine implementation.
05:36
like i said everything is built from the ground up so that basically allows us to uncover hidden patterns without- you know, without engine running into shoes with scale or performance.
05:51
and the second thing that's even even critical is the implementation itself. it's not just the design. the engine was implemented in c++ for performance reasons.
06:01
this is what enables us to provide answers in real time. because some pistons may be able to do Deep-Link-Querying and uncover data, but the response time may not be something that's useful-from a business perspective- because a lot of the
06:16
used cases like fraud and i'll require us to and even health care some of our largest customers rely on us. to uncover and provide data within seconds; micro, milliseconds in some cases.
06:30
that are operational- in use cases that are operational nature- and the implementation being in c++ allows us to provide that kind of cutting edge performance.
and now finally the storage architecture itself. it offers as the native graph database which means
06:45
index free adjacency design is built into how we store the data, so that all the connected data- by design-  is close to each other.
so that there is no need to travel-messages don't have to travel within the cluster or at least limit as much as possible.
07:08
so in total the benefit is: you're able to find hard-to-find patterns in the data easily.
07:14
you're able to support operational use cases because of the performance. and then you have a one generate system that supports both transactions and analytics which s which is a position- which is how we position our product.
07:26
now coming to the second key feature area is the scale. now you can do all of the querying. but can you handle scale as the data grows? when you go from a few gigabytes to a few terabytes and to even a petabytes.
07:40
our architecture does that. we are based on massively parallel mpp architecture massively parallel crossing architecture so everything is distributed. now as you grow as your size data sizes increased over time, you can just add hardware and you're able
07:58
to keep the same performance- an ability to support larger data sets.
08:03
and also the way we store data is in a very compressed format- so that the footprint is very small compared to the data that you bring in- that makes us efficient in terms of how we store as well as messaging if you have to communicate across nodes. everything it becomes easier.
08:21
and from a benefits perspective, basically in this way you integrate all your data your resource date systems may bring in all sorts of
08:31
data from databases files, from input streams; we are able to integrate everything in one system. and we are able to partition the data so that the load is uniformly distributed across the cluster. and also we allow
08:46
the based on the mpp architecture principles you can elastically scale these sources based on what your needs are. so, in a way that's a benefit- to only grow to the cluster to the scale that's needed
09:00
and the last aspect i want to check in the features side is the analytics themselves- for us one of the key things is in the ability to do analytics within the database itself.
09:12
and on the graph side we really didn't have a language that was rich enough to deliver that. that's why we build our own language called GSQL. this is a high level yet Turning-complete language that provides you not only the basic wherein functionality,
09:27
but also ability to add procedures that user can express logic in a very rich way.
09:35
and add to that we have user extensible graph algorithm library, all of which runs in database. so you can pretty much run any advanced analytics algorithm, machine learning algorithm, within database. that is- if you choose to. but if you want to take it out to a downstream system that that option is also available.
09:55
and the last thing i want to emphasize on the database- in database capabilities- is the
09:59
asset properties. all of our data is strongly consistent- so we ensure that all of the transaction management principles are followed- so that not only you do the analytics but you can also be sure the results are consistent- so you can support both OLTP as well as OLAP for lot.
10:18
so basically in a way you have one system where you don't have to avoid- you can avoid transferring get out of the system for each workload- but rather unify your workloads on one system.
10:32
now let's look at the architecture itself: like, how do we accomplish this? if you look at our architecture, we acknowledge that tigergraph is part of an ecosystem- so we have to pay there are other system that are 
10:48
there so we allow easy way to cohabit with other systems so that we can bring in data, historical data through our master data or operational data through our data loaders.
11:03
and also allow you to bring in data through RESTful APIs easily to injust data for any application that requires. and then of course we have the GSQL language, where you can users can bring insert data directly.
11:16
all of these go through different avenues, but they eventually reach Restpp server, which is our coordinating service
that manages when the data comes and parses and works with the engine to insert data into the engines.
^%$#
11:35
if you look at the core of the heart of the engine, there are three components that i want to spend more time on. one is the graph storage engine itself, which is where we stored the graph storage data and we stored the ID service.
11:48
so our architecture relies on- for each record there is an ID assigned external as of internal ID. so this ID service kind of translates when a data record comes. how is it stored internally in the internal format? so the graph storage service basically addresses that.
12:05
the graph processing engine is the heart of the database engine, where we performed the parallel query processing and we store the snapshots of data, 
like- if your query has updates maintaining different versions of the copies of data, all of this is handled by GPE
12:25
and for data persistence we use appache kafka for any data that comes in either through Restpp or directly through the data loaders
is first stored on appache kafka for persistence before
we push it to the engine.
12:41
so in a way, no matter what you're
input mechanism is either through the RESTful API or visual UI which is we have a graph studio ui.
that allows you to run queries and bring in data.
12:59
as well as GSQL all of them are unified through one interface, and the data is stored in the graph storage engine and processing happens in a single unified way.
and then we also know that as much as we do in database analytics,
13:15
we also see that there's a lot of customers have investments in other applications like BI tools, they may have DataBear houses where they want to take the data out of tigergraph; so we make that easy even from that perspective in the architecture.
13:30
we have a family of connectors that allow you to take the data easily out of the tigergraph as well. and that way tigergraph basically is a good citizen in terms of how it operates within the data management ecosystem.
13:46
one more aspect i wanted to touch- is the deployment itself- like distributed databases by design are obviously fundamental to  handling large loads of data, and
it is a core disant principle for tigergraph and it's very beneficial as you can see in the previous slide that i talked about.
14:08
but there is always that concern, that- with this two databases- there is an operational warhead because we are dealing with a cluster of machines as opposed to a single machine
now from an architechture perspective for deployment we have simplified that a lot.
14:23
and from a user perspective it's very simple. when you need to set up a machine you just start to figure out how much hardware you have, how many servers do you need to distribute data.
once you set that up just tell tigergraph system through the installation how many service you have.
14:39
diagraphs seamlessly distributes the data.
from a user perspective, user doesn't have to see machines as individuals but as one single database.
an even if you add more machines to it it's still the single database that they program against.
14:57
so they do not have to have any knowledge of the internals- of how the data is stored, how is it distributed and all that-
and so as your data grows from say- single terrabyte to multiple terrabytes and so on-
15:10
and the user doesn't really have to know where is the data being loaded, how is being written. all of this is these details are hidden and simplified in tumper.
15:23
and the second thing is the consistency itself- the writes that happen in in our system are HA by design. so whenever a wite comes to our system it's returned to all the replicas,
15:38
and the reads can be from any of the replicas. so as soon as the data is ingested or written, the user gets acknowledgement and then they are is ready for querying. and that way you have this it really strong consistent model.
15:53
and user doesn't have to worry about whether the data is there in the system or not from a durability perspective.
so just to recap from a deployment perspective, what are the advantages?  no matter how complicated your data needs are how large in scale you are,
16:15
the setup is still simple and simple to manage based on our retreatise.
from installation or upgrade, and other scenarios.
and from a scalar perspective, obviously it's just a matter of adding new, more hardware as your data size increases.
16:32
and the fact that we have a massively parallel processing built into our query processing- it allows you to scale and run really large queries and OLAP queries- and then the fact that we have strongly consistent asset property enforcement. this means you can run any OLTP queries at any time.
16:52
and then the last but not at least the economics of it.
the fact that we distribute the data and try to load balance everything allows you to get most out of your investment from economics perspective.
17:09
okay, so i want to switch gates now, from system architecture overview to each of the aspects of how we deal with the system.
17:20
so in this case there are different ways to bring in data into the system right? as in most cases the data comes into tigergraph from stream application or a database or even just a collection of files that have been
17:35
exported from another system. so tigergraph basically provides various different ways to ingest data. and the reason for that is we wanted to provide flexibility so that the user are the best judge of what suits for them in each case 
so let's quickly go over what the ingestion process looks like.
17:56
as i mentioned there are different ways to bring in the data, so the three key ways you bring in the data is: you can bulk load the data through files,
18:04
a bunch of files that are there through one of our loaders. or you can bring in a kafka stream that formats that are supported for this is CSV or JSON. so the second way you can bring in is through the REST services through HTTP post request: here the request has to be in JSON format.
18:22
and the third is the GSQL insert command, which is basically end user running a GSQL insert statement .
so once the request comes in, we have a service called dispatcher that takes in the data ingestion request
and starts the following process: one querry the IDS service the gsc.
18:43
to get the internal ID, because for each record that comes in we have from the external to internal that he mapping.
and after they get the internal ID, we convert that data into an internal format, and then the data is sent to one of the GPEs to do the processing and store it inside the database.
19:03
and then as each GPE consumes those updates, and - it's periodically- it will write it to disk so that memory and disk are in sync,
and here i want to quickly add one note about loading- whenever we run a loading Jobs and POST, the semantics we use are UPSERT semantics which means.
19:23
if the vertex and edge doesn't exist we create it on the fly. and if it exists already we basically update it. basically it's an idempotent operation any time any operation happens it's
if you repeat it obviously there's not going to be a duplicate there.
19:43
and a quick note on what dispatcher is- dispatcher is an internal module to schedule and dispatch tasks for a query
dispatcher is not a separate process, but it runs inside RESTpp server.  it basically assigns a particular instance of GPE.
20:02
to serve as a master- as in any mpp architecture you have a master, instance worker and worker nodes. so that the query runs in in different servers
20:17
so let's quickly look at one example: here's one scenario of data load- data load. that can be brought in other settings. as in CSV or JSON format, first the data load request is pass to Restpp, load it through.
20:32
the Nginx load balancer from Restpp the data updates are returned to kafka for initial persistence.
this ensures that the durability of data is there before we write it to the tigergraph system.
20:46
now kafka write-ahead-log here is essential because it allows us to reread the data if there is if there is any need, and the internal kafka clusters that are used are
20:58
organized based on the cluster layout, like for example: kafka topics that we set up are arranged based on the number of partitions in the cluster.
so data belonging to a particular partition which is categorized by each vertice type.
is sent to the corresponding kafka topic.
21:18
and from that kafka topic GPE ingests the data into memory that updates are held in memory and is available for querying immediately.
21:26
and acknowledgement being sent to the users basically indicating that the data is ready. and then we have a background process called rebuild that from time-to-time compacts all the updates in memory and writes to the disk so that the disk and memory are in sync
^%$#
21:44
so this is kind of the high level overview of how ingestion request would go through the system 
into the disk.
21:55
so one other thing i want to do. emphasize when i say internal format and how we store data i wanted to quickly define a few things. as to what is stored in exactly inside the database. tigergraph is the native
22:11
graph store so when we write data to the disk our goal is to make it easy for travel to people later. so here are the principles again of index three adjacency.
22:24
come in to a picture. so the three things we store. for each record are are listed. first is the IDS, which is basically the biodirectional mapping between external and internal ID of each record in the database.
22:37
the second is obviously the vertex data as you store vertx partition data all of the attributes for each vertex are stored alongside in the same location so they're co-located.
22:47
and the edge data is also stored equally located. an edge data is basically partitioned by source and target internal id keys and then obviously all of the attributes of the edge also stored together. so these three pieces of information are stored in segments 
23:07
inside each partition and the principles there are
so the data is automatically partitioned to distribute across the cluster, so there's two concepts that i want to highlight: one is the concept of partition and the second one is segment.
23:24
partition is the unit of the division of resources in the cluster so the goal is to partition resources uniformly across the cluster. basically this allows for even distribution of the lowered inter and the resource usage later
23:40
so partition data is again its broken down into a smaller units called segment. and segments are picked in such a way that each segment belonging to the same vertex type.
23:53
is stored together. and this basically ensures your data locality so that you minimize the need for movement of data across clusters as much as possible. as you can see in this example here, each segment,
24:08
all of the data belonging to each vertex and edge- that is by ID is co-located in each segment and in each partition together. and location of any of the vertex can be easily calculated. based on the internal ID and vice versa translation can happen.
as needed during the query processing.
24:30
so that's the ingestion process now moving on to the query processing which is a little bit more complicated because as we support multiple workloads, 
there are different ways to handle query processing. i'll go around few details in this in this section
24:50
so first let's go over the what the workflow looks like for a query processing. so user runs a GSQL or a graph studio query or or a RESTful API calls to submit using HTTP request, once the user submits the server parses the request based on the graph schema and forwards it to the dispatcher.
25:11
and the dispatcher will query the ID service to convert it, convert the request from the internal format to the external, and also assign a particular GPE as the master-for that query.
25:22
and from that point onwards GPE performs the computation based on the user logic of what the query is, and then returns back to dispatcher the the run result and this is again sent back to the REST server
25:35
from REST server obviously the result  is sent back as a HTTP request in JSON format back to the user. fairly high level of what the workflow would look like.
now
if you
25:49
one thing i want to, before i go further into the details about the query processing, i wanted to spend a few minutes on 
how the memory is used(memomry usage), because memory is so vital to how
tigergraph performs, i wanted to spend a couple of minutes on that.
26:07
the reason why it's so important is because the way you optimize the memory usage helps the query performance; more memory, if it's available to system, there's more opportunity to speed up the performance
26:18
so here the way memory is divided is in two broad categories(in tigergraph): one is the static reserved memory that is always used by system, and the second one is more query level uses that can change depending on the load. so any directions we do with the system level static can mean more memories available for query processing
26:38
in terms of the first category- the static memory- let's start on the right side.
here there are two key principles. one is the GPE which stores all of the partition data- all of the graph data including vertex, edge attribute all of this is pre-loaded by default in memory. and the second
27:01
chunk of memory that 's utilized is by GSE for IDS, where we preload all of the IDS data in memory. so this is something that's a constant and it's configurable, where users can set limits of how much memory they want to retain for the data.
and how much they want to put it in disk
27:21
but the other aspect of memory that's used is dynamic- which is basically depending on what query is running- here as you can see bulk of the query come from accumulators- concept i'll explain later.
and there are also some of the memories used by shuffles,
27:43
it's also memory used by- if the query has upserts then we need to maintain copies of the data which means aditional memory is required from a GPE perspective.
so all-in-all you have
27:59
two sets of categories of memory one is the static one that you can in can figure that from a operational perspective the second aspect the query it's a dynamic memory that is something that
28:14
can be optimized based on your best practices and that's where a lot of the a training helps- to get more out of tigergraph system in terms of memory usage.
okay. so let's look at query processing workflow
^%$#
28:35
so here if you look at a typical processing, let's start from the top. request comes in: the incoming requests have details such as query name, parameter, and schema informations such as vortex type, it goes through
28:50
Nginx again. to Restpp, parses the request. and the first action is Restpp will send the request to GSE to get the- to translate- external ID into the internal ID
and at the same time Restpp will send through the dispatcher to the master GPE the query name or the parameters.
29:12
and after GSE returns the internal ID, the processing moves to GPE, and at this point onwards GPE will basically do the query processing based on the user logic and all of the computations
are performed depending on if it's a simple query or it's a distributed query.
29:33
after all the processing is completed, GPE responds back to GSE to get the external ID of the
vertex that's in question.
and sends the JSON response back to Restpp, basically returning the result of the query. and the Restpp then combines the
29:51
responses from all and then sends it back to Nginx and the query result is finally returned
back to the user.
this is kind of the high level overview of how
30:01
query workfold occurs
one thing i want to spend a minute on is: i know there are multiple ways to query data from tigergraph, but GSQL is probably the most comprehensive one, and  there's a number of reasons for that: one, because GSQL is based on schema
30:19
based query language, it allows you to have integrity checking, it allows you to basically make your app development data independent. you don't have to have knowledge of how the data is stored so it kind of helps from that perspective. and also
30:34
we have built in some high performance features like accumulators that allow you to work independently in parallel towards
^%$#
30:45
improving the performance and also GSQL is like SQL you know the familiarity of all the SQL users their input is taken into GSQL so someone coming from SQL can easily understand GSQL syntax and can it gets started easily.
31:04
and in addition to that we also made it easier to implement algorithms a lot of the control flow functionality, like for example loop seen in programming languages are are available to the GSQL.
31:19
and then you can parameterize query so that you can reuse the cord so all of this makes it easy for complex query to be reused as much as possibe. and finally GSQL also supports transaction graph updates, which basically makes it suitable for both analytical as well as 
31:37
transactional used cases so you can use it both.
now i want to spend a minute a few minutes on what are the different querying patterns themselves?
31:50
and if you think about mpp system it's not a one single system it has it depends on the type of workload you run, the system is able to adjust, and provide a way to a leverage resource in the most optimal way.
32:07
so we have in our system two modes in which you run queries one is called a single server mode and the second is distributed mode a single sever mode as the name suggests basicalally 
32:21
it concentrates all of the query processing on a single server like for example: if you have a query that a simple query then in the cluster elcets one server to be the master.
32:32
and all of the computations happen in that master. an if the data is not in that particular server we actually copy all of the data and bring the data to that particular node and then all of the processing happens in that single node.
32:45
and this is useful for simple queries where you are only dealing with a subset of vertices. now the second one other other mode is the distributed mode now as the name suggests this 
33:00
in contrasting with the single server mode here the parsing is totally distributed. the server still picks the master, and
33:15
the worker nodes are all working in parallel to do the computation. so here again the power of accumulators comes into picture. any query that's running in parallel all of the computations that have to happen in parallel happened.
and the results are aggregated at the very end and then the query
33:39
basically the pora pallithm comes into picture here. so if your query is something that uses all of the vertices or most of the vertices of the graph, then this is a good way because then you're bringing all the power of entire cruster for
query processing
33:53
so again to do a quick recap of where to see which one is useful, so if you're starting with a small, single number of vertices, then single mode is best
example: point querry- we call point query: one that is where
the predicates are very simple,
34:15
or you can deal with the vertices. a small subset of vertex data than a basically like transactional queries or dp queries. these are the ones that are best fit for single server mode.
34:26
now if you have complicated algorithms, graph algorithms or OLAP style queries that that required a large number of vertices/edges to be traveled, then obviously you should use distributed mode. and obviously here like example: PageRank,
34:42
Centraily, Louvain- these are the sort of algorithm that typically require you to deal with entire data set- so those would be the ones that would be a good candidate for distributed mode. 
34:54
i want to spend a couple of minutes on accumulators that i did make a mention about you know the fact that they are unique in the industry in graph database,
35:09
so i want to spend a couple of minutes on that. accumulators are a new innovation from graph database they kind of allow us to enable parallel processing the data as much as possible. as the name suggests accumulators basically accumulate information about the graph during traversal
35:29
and they enable multi thread processing as much as possible.
 to speed up your querying
35:35
so accumulators work in two phases: an in phase one basically you receive messages and during the traversal accumulators hold the all of the message data in a bucket that belongs to the particular accumulator.
35:50
in phase two the accumulator will aggregate based on the type of aggregate function, that's defined, and compute the value, and provide it for the query
so again in terms of accumulators, there are two types: there is one local accumulator and then there is the global accumulator.
36:10
local accumulators store data about each vertex and can only be accessed by the transversal instance. they're basically run time attributes for attribute if you run into the same vertex again then obviously you can use this in the same query block. you'll be able to use that information.
36:26
contrast that with the global accumulators that store information about the entire graph and they can be accessed by any node
and if you look at the accumulators like i said there are different aggregate functions that can be performed using accumulators. the ones we have are:
36:49
SumAccum, which keeps running total of the integere totals its basically a cumulative concatenation of all the values that are there.
and then next we have Min and MaxAccum, which obviously stored the least or the greatest value of a series of values that that are encountered in a traversal.
37:07
and then of course we also have the average- which computes the average and stores the mean value for a series of numeric values- that are seen 
in the graph 
37:19
so these are very useful for OLAP queries where if you want to push down the competition to the worker level as much as possible, rather than have it bringing data into the master node,
basically implementing it in the true distributed computing model.
37:39
so this is a quick overview of the ingestion in the query processing aspect, so now we want to shift gear to non-functional features.
victor will go over that, Victor are you ready?
37:55
Thank you Rayees! yeah. great job. so i'm going to cover three areas: high availability, access control& security, and transaction management.
38:04
so if we go to the first slide on high availability, and so as Rayees showed you earlier you can have a distributed system and you can have replicas of that. and so i'm going to introduce a couple of terms; P is the partitioning factor
38:19
so if my database is spreading the data across 5 servers, that's the partitioning factor- it's five- and then, if i have two replicas of that entire database, then my replication factor is 2
38:34
so i have a total of 10 servers. and this is a pretty- you know, traditional architecture- that gives you both; now depending on what exactly a replica can do; whether it's an active-active replica whether it's a read-write
replica or not- depends on what benefits you get- because our replicas
38:54
are active-active, they are read-write, meaning they're always in sink.
every replica has the same data when a transaction finishes, then you get both increased throughput.
and you have the benefit of a continuous operation if you've engineered it correctly.
39:12
so again, that's some basics; let's go onto the next slide to look at how you get that throughput. and so now i've numbered the system so they're one through five, going across the partition and A, B to refer to the replicas.
39:29
so and we say each server- this is a configuration factor in the tigergraph software- you can say each server has a certain number of available workers
39:42
for serving request such as a GSQL query, REST POST request, etc. the default's to eight, but you can set it higher. and you might want to be thinking about how many cpu cores you have- because there's a correlation
39:57
it doesn't have to be the same number, but it's it's influenced by that. what sort of performence you get. so that means the total number of workers you have available is =  TxPxR. so in this example i gave- if we have 8
workers per machine- then you have 80 workers.
40:16
a point mode query- when Rayees earlier was talking about- the two processing modes for queries.
a point mode query uses one worker the worker has to be in charge.
other servers may assist but we'e referring to who's kind of doing coordination work.
40:36
a distributed mode query, on the other hand, uses a worker on every server across
one replica so it's using P workers. so that means you can- you have a lot higher level of concurrency- if you're doing
point mode. you still have-
40:55
you can still have very good concurrency in distributed mode, but it's going to be somewhat lower.
41:00
and so that's basically the scheme for- you know, we didn't go totally; i'll say a little bit more when we get to transaction management, about how the concurrency happens, but this is explaining the level of concurrency that is possible.
41:15
in the next slide i'll get into what happens when one of those nodes goes down.
so next slide please
41:25
yeah.
oh, okay.
41:30
so,
we're designed to provide continuous operation. so if any single server goes down, either because you intentionally take it down for service,
or there's a failure- so it's unexpected.
41:44
you know the other machines- we'll be trying to contact it- and if it fails to respond after a certain number of tries, then the request will automatically divert to another replica. for example: 3b is unavailable, then the request will shift to 3a.
42:02
and so it may happen if that failure happens in the middle of a transaction. probably that transaction is going to be aborted.
but if
42:11
but, if a new transaction starts- already sees that 3b is not available, it will just work around it and go to 3a- and so other subsequent transactions will run fine so there is a continuous operation.
there will be obviously reduced throughput, but
42:29
you won't have to go down while you're trying to make repairs or do your service work. there will be a short pause while you bring it back online, and we're working to a even cut down on that- time when you bring it back online.
42:45
so that is our basic story on HA. i'm sure there'll be some questions later, but we're going to move on to access control. and i'm going to cover a couple of things here: first of all, we feature role-based access control in industry standard
43:00
model for how enterprises would like to see- roles and privileges and users managed. so we very much followed the language semantics and of language syntax, and semantics of
sequal- so you can grant or revoke a role or privilege
43:20
on a graph, instead of a table- and then two: one or more users.
and you can also map those roles to external LDAP roles and groups so you can combine the roles you have- with tigergraph- and sink them with the roles on other parts of your larger infrastructure.
43:44
so i'm going to go into a little bit more depth, you can also manage the roles in the latest version of graph studio, which includes a adman portal upgrade, so you can see the different users,
43:59
and different privileges are listed there. and so you can gather lines of code, you can manage them and an admin user can manage them through a UI.
the next thing i want to talk about is the graph component, so i said a privilege- is there's a role or privilege
on a graph
44:18
for
some number of users- and a unique feature, and benefit of tigergraph systems is the multigraph feature.
it's the way that you can define subsets,
44:30
subgraphs or views within your larger graph.
that not only can be used for pure isolation, such as multi tenancy, you can have completely separate data domains, but you can also intentionally choose to overlap them. and so then you're
44:49
enabling sharing- and as the picture shows- you can have regions- like the product group- they have some data which is only theirs, they have some data which they share with IT, they have some data which they shared with the customer department,
45:04
and they have some data which all the teams can see. and you can very easily define very sophisticated combinations of both private and shared data.
and because it's actually shared, not copied,
45:21
you're guaranteed consistency, it's less expensive- because there's less hardware- there's only one copy of the data. so it's consistent so it's cleaner, faster, cheaper, and safer. and as i said, each group
45:36
also will have its own administrator- so that's their world view- they don't see the other groups at all, unless the superuser enables them to see the other groups, so within each group it's like they have their own graph, they manage their own affairs
45:51
as and it's a great two-tier model. of global and local privileges, and you can do really interesting combinations of how you define those graphs to achieve really interesting results. and we're going to have to move on.
so we can try to wrap up on time.
46:10
we have a number of built-in roles and we currently have user defined roles in development.
so for the built-in roles it really follows a
a hierarchy.
46:23
as well as two different branches. there is- you know- those who are designing the graphs and designing the queries, and those who are managing users. so you know at that the lowest level-
46:38
this is i've written down the lowest level query reader- and the top level is obviously superuser, but i'm not going to spend the time to go through
everything here,
but, 
46:51
you can see-
you've got- even with the built-in rolls, you have
pretty fine-grained access control and we're going to be giving you even finer-grained control in the near future.
47:08
so i'm going to move on to data encryption: so we're kind of generally talking about security, so obviously this is very important to a lot of users, and there are two basic
things that enterprises need: they may want the data to be encrypted
when it's stored at REST, as we say,
47:29
and also when it's being sent from one place to another-
encrypted in transit- so for at REST, we give you a choice of several different encryption levels, it could be file level, volume, partition, or disk,
and we give you a choice of techniques you can use.
47:50
if you're doing kernel level encryption- where you need
a superuser privilege on the machine- one of the most popular approaches is to use the built in linux utilities, dm-crypts and cryptsetup. if you don't have that option or don't want
48:10
to do it at the superuser kernel level, you can do it at the user level using FUSE.
tigergraph cloud, by the way, automatically is encrypted so nothing you have to do there.
48:24
before encrypting data in transit, you can set up SSL/TLS so that it's using the secure HTTP protocol. it's a fairly standard process of getting a certificate, and you know a just a few configuration commands in you're set, because:
as Rayees mentioned, we use
REST
48:46
we use a lot of REST requests, which make use of the HTTP protocol. so even within our own system- internally, we're using http- as well as for possible external communication.
49:02
so this is something that we've thought about early on, and so it's fairly straightforward. and also it's automatically encrypted in tigergraph clouds, so nothing for you to do there.
and that's the security topic and i'm going to move on to the last topic- transaction management.
49:22
 so we are distributed database, and we are a full ACID database. using the sequential consistency model. you know there are a lot of different consistency models these days, and so sometimes you need the fine print and so we're going to
49:37
have just enough time here to give you the overview of what model we followed. so first of all what is a transaction in tigergraph?
so when we say a query- and this is where it's a little different. it's because of the programmability of GSQL language our queries are procedures with a name
50:02
and with a parameter list, input parameter list and within it, it can have multiple statements, such as: select, insert, update, it can also have flow control- like for loops and while loops.
50:17
if/else case, but we consider one query- which is a procedure- to be a transaction. so clearly, you can have both read and write operations in it
it could be read only, it could be write only, it could have both.
50:32
also if a user is doing things just as a REST request, one REST request is a transaction. so that's the model of what is a transaction.
and then we're going to go into the ACID compliance level.
so we have A, C, I, D, acid,
50:51
atomicity,
i already explained what is a transaction, and so
obviously they are all or nothing. either it completes.
51:00
completely, successfully, or not at all. like i mentioned, if if there is a the failure of one machine in the middle of a transaction, that one will probably fail, and so none of the changes regarding that transaction will take place.
51:19
consistency model: the term AICD was defined before distributed systems were popular. when they defined ACID, they were really talking just about single servers. so the original meaning of consistency
has to do of just: is your transaction obeying some basic data validation rules; such as referential integrity.
51:43
and so, obviously, we obey those. a what's really interesting to people these days is: what sort of distributed system consistency do you have, and so as we said we have sequential consistency, which means each replica of the data performs the same operations in the same order or same sequence.
52:04
moving on to isolation level, with very strong isolation. we guarantee repeatable reads. because each transaction sees the same data within that transaction, if you read something at the beginning, read something in the middle, read something
52:19
at the end, if you haven't made any updates, you're going to be reading the same data no change there.
and no dirty or phantom reads.
if one transaction makes some updates, other transactions are not going to see those updates
52:36
until they're officially committed.
so we got strong isolation there. and durability: and i think this even relates a little bit to maybe or peripherally to a question that came in about a different database. we use
write-ahead-loggig
52:55
so that as Rayees mentioned the updates are written to disk
at the beginning
and they stay there in a log.
53:05
so that you've got that durability.
but
that log is not what you considered you know- the database proper- the database proper is
53:15
conceptually that's the graph
so periodically we
consume the recent logs to update the graph.
53:28
but because you've got those logs, there's a guarantee that you can take the current
graph and the as yet-unprocessed logs to reconstruct what the graph should be- and in fact that even is used in concurrency- because other transactions are taking place
53:49
before the graph has been fully updated, so they're using those logs to understand what's the current state of the graph.
and that basically that's all the time we have to do for presentation, we have a lot of questions.
54:03
we have a lot more information you can find on the web- please contact is if you have more questions- but let's get right to some of these questions.
i'm just going to go top from bottom i'm going to
read them out loud and sort of- between Rayees and i- will decide on who actually answers it.
54:27
does the storage engine manage partitioning under the hood?especially as you scale out horizontally?
Rayees?
54:37
yeah. from a scaling perspective it is like i said- the principles of mpp take over here- basically the auto partitioning, basically we have an
algorithm that distributes data evenly. so from
55:00
user perspective it is totally transparent to them. we basically handle it as part of our design.
55:08
okay. number two: how do you hide communication latency when fetching data from a remote processor? how do you load balance work across processors? so i'll take that one.
what we have is: we have minimal communication latency because we are being
55:29
very careful about how much and what we need to communicate across the graph. now we don't make wild claims about doing an optimal partitioning of the graph, because that's an NP hard problem it's not doable.
what we do, as Rayees showed,
we
55:47
we do as much locally as possible, and then only transmit the data that needs to be known
by the other systems, so it's not a question of hiding the latency; it's about minimizing what needs to be done, and it's about working-
56:04
while you're working within the machine, you're going as quickly as possible. how do we do load balancing? we have a number of schemes you know we start off with round robbin,
i showed earlier how many different
workers are available, so you know- the the masters who are in charge of
56:29
query are looking at to see who's available- and and it's also up to the workers to respond about whether they're available, how much load they currently have
56:41
so despatcher has the cluster. so dispatcher kind of knows what is the level of activity on each nord, so the dispatcher decides where to assign the queries.
56:54
third: can you share numbers around high transactions supported for ACID- basically how many transactions can we handle simultaneously? you know, there's a lot of- system dependent-
57:09
issues there, so we can get back to you with some numbers .
fourth: your data sources- how would i connect to solutions like share point or open text?
57:22
so, you know the general mode- is our basic format- is: we read from files or from kafka or from certain data stores, we also have a JDBC connector, and will soon have an ODBC connector, so 
57:40
if you have one of those standard formats, we can work. so you know- the bottom line is also well- if you can put your data into a what looks like a file we can read from the file, but if you're looking for a more 
57:55
app-to-app connection, we have JDBC and we'll soon have ODBC and our community is building lots and lots of more connectors.
let's see how much more time we have.
for HA on AWS how do you deal with or support
58:11
multiple regions-in terms of acid- writing to all nodes in the cross region latency?
that might be the last question we have time for,
Rayees, do you want to take that one about cross region?
58:25
cross region perspective single cluster you can set up a cross region, but you have to be cognicent about the network latency. we rely on AWS cross region replication mechanism to do that.
58:40
now if you want to have clusters set up- disparate clusters across regions; that's a feature in development right now. because you could set it up yours with in we have a solution in that customers can implement
58:55
but to do it natively both for data operations as well as meta data operations, that is a feature in development and will be available soon by the end of the year.
59:05
i'm going to handle on two more very quickly.
replicating data eats up a lot of memory. well, if you look at our replication model, it's based on setting up another
59:17
copy of the servers- and that's just the standard model. we have data compression, so if you have x number of bytes of data externally, when it's loaded on a tigergraph. chances are: it is only half the size.
so it may not be as much memory as you think.
59:38
in other systems- other systems require replication just to operate- we don't require that.
for us replication is just because either you want higher throughput
59:52
or you want higher protection against you know- possible hardware failures or what not. other systems- like cassandra- you have to replicate, or pretty much it's very strongly recommended. for us is it's merely your decision.
01:00:09
and the last question: how do we handle errors during bulk loading?
we do line-by-line checking, the log, we will tend to, if there is some reason why a single line cannot be processed, the error type will go into the log and it will move on. so it's going to
01:00:29
just process every single line or every single JSON object individually. it will log a bunch of different errors at encountered, and you can look at the log when you finished.
01:00:40
and i think that's all the time that we have we want to thank everybody for joining us today. you have been part of one of our biggest webinars ever- certainly the most questions i can ever recall receiving- and we will answer
01:00:55
the questions individually getting back to you if we weren't able to answer it online today.
i'm not sure if emily is on there
01:01:06
i think i want a second, Victor; for all the interests that you've shown, and if you are new to a tigergraph, you can try- very easily- tigergraph cloud, easy to set up and test drive yourself.
01:01:21
you can also download developer's edition to get more on your own environment, and then the resources are all there. there's a growing community, very vibrantly managed by ardout of bari angelist.
01:01:36
we can answer questions, and also there's also a tigergraph certification program, if you really want to get certified in tigergraph internals.
01:01:47
thank you again; be looking forward to hearing from you again
01:01:53
thank you